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Preface 



This volume contains the proceedings of AMAST 2004, the 10th International 
Conference on Algebraic Methodology and Software Technology, held during 
July 12—16, 2004, in Stirling, Scotland, UK. The major goal of the AMAST con- 
ferences is to promote research that may lead to the setting of software technol- 
ogy on a firm, mathematical basis. This goal is achieved by a large international 
cooperation with contributions from both academia and industry. The virtues of 
a software technology developed on a mathematical basis have been envisioned 
as being capable of providing software that is (a) correct, and the correctness can 
be proved mathematically, (b) safe, so that it can be used in the implementation 
of critical systems, (c) portable, i.e., independent of computing platforms and 
language generations, and (d) evolutionary, i.e., it is self-adaptable and evolves 
with the problem domain. 

Previous AMAST meetings were held in Iowa City (1989, 1991, 2000), Twente 
(1993), Montreal (1995), Munich (1996), Sydney (1997), Manaus (1999), and 
Reunion Island (2002), and contributed to the AMAST goals by reporting and 
disseminating academic and industrial achievements within the AMAST area 
of interest. During these meetings, AMAST attracted an international following 
among researchers and practitioners interested in software technology, program- 
ming methodology and their algebraic and logical foundations. 

For AMAST 2004 there were 63 submissions of overall high quality, authored 
by researchers from Australia, Canada, China, the Czech Republic, Denmark, 
France, Germany, India, Iran, Israel, Italy, Korea, Portugal, Spain, Taiwan, The 
Netherlands, Turkey, the UK, and the USA. All submissions were thoroughly 
evaluated, and an electronic program committee meeting was held to discuss the 
reviewers’ reports. The program committee selected 35 papers to be presented. 
This volume includes these papers, and abstracts or papers of invited lectures 
given by Roland Backhouse, Don Batory, Michel Bidoit, Muffy Calder, Bart 
Jacobs, and John-Jules Meyer. 

We heartily thank the members of the program committee and all the referees 
for their care and time in reviewing the submitted papers, and all the institu- 
tions that supported AMAST 2004: the Edinburgh Mathematical Society, the 
Engineering and Physical Sciences Research Council, the London Mathematical 
Society, and the Formal Aspects of Computing Science specialist group of the 
British Computer Society. 
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Algebraic Approaches to Problem Generalisation 



Roland Backhouse 

School of Computer Science and Information Technology, University of Nottingham, 
Nottingham NG8 IBB, England 
rcbOcs . nott .ac.uk 



Abstract. A common technique for solving programming problems is 
to express the problem in terms of solving a system of so-called “simul- 
taneous” equations (a collection of equations in a number of unknowns 
that are often mutually recursive). Having done so, a number of tech- 
niques can be used for solving the equations, ranging from simple iter- 
ative techniques to more sophisticated but more specialised elimination 
techniques. 

A stumbling block for the use of simultaneous equations is that there 
is often a big leap from a problem’s specification to the construction 
of the system of simultaneous equations; the justification for the leap 
almost invariably involves a post hoc verification of the construction. 
Thus, whereas methods for solving the equations, once constructed, are 
well-known and understood, the process of constructing the equations is 
not. 

In this talk, we present a general theorem which expresses when the solu- 
tion to a problem can be expressed as solving a system of simultaneous 
equations. The theorem exploits the theory of Galois connections and 
fixed-point calculus, which we briefly introduce. We give several exam- 
ples of the theorem together with several non-examples (that is, examples 
where the theorem is not directly applicable). The non-examples serve 
two functions. They highlight the gap between specification and simul- 
taneous equations - we show in several cases how a small change in 
the specification leads to a breakdown in the solution by simultaneous 
equations - and they inform the development of a methodology for the 
construction of the equations. 

Application of the technique in the case of the more challenging prob- 
lems depends crucially on finding a suitable generalisation of the original 
problem. For example, the problem of finding the edit distance between a 
word and a context-free language is solved by computing the edit distance 
between each segment of the given word and the language generated by 
each nonterminal in the given grammar. 

A focus of the talk is the use of Conway’s factor theory [Con71] in gener- 
alising a class of problems we call “bound” problems. Since its publica- 
tion in 1971, Conway’s work has been largely ignored, but its relevance 
to program analysis has recently been observed by Oege de Moor and 
his colleagues [MDLS02,SdML04]. We show how factor theory underpins 
Dc Moor’s work as well as the well-known Knuth-Morris-Pratt pattern 
matching algorithm [KMP77]. We also speculate on how further study 
of factor theory might have relevance to a broader class of problems. 
This talk is based on [Bac04], where further details can be found. 
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A Science of Software Design 
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Abstract. Underlying large-scale software design and program synthesis are 
simple and powerful algebraic models. In this paper, I review the elementary 
ideas upon which these algebras rest and argue that they define the basis for a 
science of software design. 



1 Introduction 

I have worked in the areas of program generation, software product-lines, domain 
specific languages, and component-based architectures for over twenty years. The 
emphasis of my research has been on large-scale program synthesis and design auto- 
mation. The importance of these topics is intuitive: higher productivity, improved 
software quality, lower maintenance costs, and reduced time-to-market can be achiev- 
ed through automation. 

Twenty years has given me a unique perspective on software design and software 
modularity. My work has revealed that large scale software design and program syn- 
thesis is governed by simple and powerful algebraic models. In this paper, I review 
the elementary ideas on which these algebras rest. To place this contribution in con- 
text, a fundamental problem in software engineering is the abject lack of a science for 
software design. I will argue that these algebraic models can define the basis for such 
a science. 

I firmly believe that future courses in software design will be partly taught using 
domain-specific algebras, where a program’s design is represented by a composition 
of operators, and design optimization is achieved through algebraic rewrites of these 
compositions. This belief is consistent with the goal of AMAST. However, I suspect 
that how I use algebras and their relative informality to achieve design automation is 
unconventional to the AMAST community. As a background for my presentation, I 
begin with a brief report on the 2003 Science of Design Workshop. 



2 NSF’s Science of Design Workshop 

In October 2003, 1 attended a National Science Foundation (NSF) workshop in Airlie, 
Virginia on the “Science of Design” [11], The goal of the workshop was to determine 
the meaning of the term “Science of Design”. NSF planned to start a program with 
this title and an objective was to determine lines of research to fund. There were 60 
attendees from the U.S., Canada, and Europe. Most were from the practical side of 
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software engineering; a few attendees represented the area of formal methods. I was 
interested in the workshop to see if others shared my opinions and experiences in 
software design, but more generally, I wanted to see what a cross-section of today’s 
Software Engineering community believed would be the “Science of Design”. In the 
following, I review a few key positions that I found particularly interesting. 

Richard Gabriel is a Distinguished Engineer at Sun Microsystems and one of the 
architects of Common Lisp. He described his degree in creative writing - in particu- 
lar, poetry - and demonstrated that it was far more rigorous in terms of course work 
than a comparable degree in Software Engineering (of which software design was but 
a small part). He advocated that students should be awarded degrees in “Fine Arts” 
for software design. I was astonished: I did not expect to hear such a presentation at a 
Science of Design workshop. Nevertheless, Gabriel reinforced the common percep- 
tion that software design is indeed an art, and a poorly understood art at that. 

Carliss Balwin is a Professor at the Harvard Business School. She argued that 
software design is an instance of a much larger paradigm of product design. She ob- 
served that the processes by which one designs a table, or a chair, or an auditorium, 
are fundamentally similar to that of designing software. Consequently, software de- 
sign has firm roots in economic processes and formalisms. Once again, I was not 
expecting to hear such a presentation at a Science of Design workshop. And again, I 
agreed with her arguments that software design can be viewed as an application of 
economics. 

Did the workshop bring forth the view of is software design as a science ? I did not 
see much support for this position. Attendees were certainly using science and scien- 
tific methods in their investigations. But I found little consensus, let alone support, for 
software design as a science. The most memorable summary I heard at the workshop 
was given by Fred Brookes, the 1999 ACM Turing Award recipient. He summarized 
the conclusions of his working group as “We don’t know what we’re doing, and we 
don’t know what we’ve done!”. 

The results of the workshop were clear: if there is to be a science of software de- 
sign, it is a very long way off. In fact, it was questionable to consider software design 
a “science”. Although I do not recall hearing this question posed, it seemed reason- 
able to ask if design is engineering 1 . For example, when bridges are designed, there is 
indeed an element of artistry in their creation. But there is also an underlying science 
called physics that is used to determine if the bridge meets its specifications. So if 
software design is engineering, then what is the science that underlies software de- 
sign? Again, we are back to square one. 

After many hours of thought, I realized that the positions of Gabriel and Baldwin 
were consistent with my own. Software design is an art as Gabriel argued, but not 
always. Consider the following: designing the first automobiles was an art - it had 
never been done before, and required lots of trial and error. Similarly, designing the 
first computer or designing the first compiler were also works of art. There were no 
assembly lines for creating these products and no automation. What made them possi- 
ble was craftsmanship and supreme creativity. Over time, however, people began 
building variants of these designs. In doing so, they learned answers to the important 
questions of how to design these products, what to design, and most importantly, why 
to do it in a particular way. Decision making moved from subjective justifications to 
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quantitative reasoning. I am sure you have heard the phrase “we’ve done this so often, 
we’ve gotten it down to a science”. Well, that is the beginnings of a science. 

A distinction that is useful for this paper is the following: given a specification of a 
program and a set of organized knowledge and techniques, if “magic” (a.k.a. inspira- 
tion, creativity) is needed to translate the specification into a program’s design, then 
this process is an art or an inexact science. However, if it is purely a mechanical pro- 
cess by which a specification is translated into a design of an efficient program, then 
this process follows an exact or deterministic science. 

Creating one-of-a-kind designs will always be an art and will never be the result of 
an exact or deterministic science, simply because “magic” is needed. Interestingly, the 
focus of today’s software design methodologies is largely on creating one-of-a-kind 
products. The objective is to push the envelope on a program or component’s capa- 
bilities, relying on the creativity and craftsmanship of its creators - and not automa- 
tion. In contrast, I believe that an exact science for software design lies in the mecha- 
nization and codification of well-understood processes, domain-expertise, and design 
history. We have vast experiences building particular kinds of programs, we know the 
how, the what, and the why of their construction. We want to automate this process so 
that there is no magic, no drudgery, and no mistakes. The objective of this approach is 
also to push the envelope on a program or component’s capability but with emphasis 
on design automation. That is, we want to achieve the same goals of conventional 
software development, but from a design automation viewpoint. 

The mindset to achieve higher levels of automation is unconventional. It begins 
with a declarative specification of a program. This specification is translated into a 
design of an efficient program, and then this design is translated to an executable. To 
do all this requires significant technological advances. First, how can declarative 
specifications of programs be simplified so that they can be written by programmers 
with, say, a high-school education? This requires advances in domain-specific lan- 
guages. Second, how can we map a declarative specification to an efficient design? 
This is the difficult problem of automatic programming ; all but the most pioneering 
researchers abandoned this problem in the early 1980’s as the techniques that were 
available at that time did not scale [1]. And finally, how do we translate a program’s 
design to an efficient executable automatically? This is generative programming [9]. 
Simultaneous advances on all three fronts are needed to realize significant benefits in 
automation. 

To do all this seems impossible, yet an example of this futuristic paradigm was re- 
alized over 25 years ago, around the time that others were giving up on automatic 
programming. The work was in a significant domain, and the result had a revolution- 
ary impact on industry. The result: relational query optimization (RQO) [12]. 

Here’s how RQO works: an SQL query is translated by a parser into an inefficient 
relational algebra expression. A query optimizer optimizes the expression to produce 
a semantically equivalent expression with better performance characteristics. A code 
generator translates the optimized expression into an efficient executable. SQL is a 
prototypical declarative domain-specific language; the code generators were early 
examples of generative programming, and the optimizer was the key to a practical 
solution to automatic programing. 

In retrospect, relational database researchers were successful because they auto- 
mated the development of query evaluation programs. These programs were hard to 
write, harder to optimize, and even harder to maintain. The insight these researchers 
had was to create an exact or deterministic science to specify and optimize query 
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evaluation programs. In particular, they identified the fundamental operators that 
comprised the domain of query evaluation programs, namely relational algebra. They 
represented particular programs in this domain by expressions (i.e., compositions of 
relational operators). And they used algebraic identities to rewrite, and thus optimize, 
relational algebra expressions. 

RQO is clearly an interesting paradigm for automated software development [5]. I 
cannot recall others ever proposing to generalize the RQO paradigm to other domains. 
The reason is clear: the generalization is not obvious. It is possible, and in the next 
sections, I show how. 



3 Feature Oriented Programming 

Feature Oriented Programming (FOP) originated from work on product-line 
architectures. The goal is to declaratively specify a program by the features that it is 
to have, where a feature is some characteristic that can be shared by programs in a 
domain. So program PI might have features X, Y, and Z, while program P2 has 
features X, Q, and R. Features are useful because they align with requirements: 
customers know their requirements and can see how features satisfy requirements. 

Interestingly, feature specifications of products are quite common. (It just isn’t 
common for software). The Dell web site, for example, has numerous web pages 
where customers can declaratively specify the features they want on their PCs. A Dell 
web page is a declarative DSL; clicking the check boxes and selecting items from 
pull-down menus is the way declarative specs are written. By sending Dell a check for 
the computed amount, that customized PC will be delivered in days. Similarly, order- 
ing a customized meal at a restaurant involves choosing items from a menu; this too is 
a familiar form of declarative specifications. Neither customizing PCs or ordering 
customized meals requires an advanced technical degree. We want the same for soft- 
ware. 

GenVoca is a simple and powerful algebraic model of FOP. GenVoca is based on 
the idea of step-wise refinement, which is an ancient methodology for building soft- 
ware by progressively adding details [14]. The novelty of GenVoca is that it scales the 
concept of refinement. That is, instead of composing hundreds or thousands micro- 
scopic program rewrites called refinements, GenVoca scales refinements so that they 
each encapsulate an individual feature. A complete program is synthesized by com- 
posing a few feature refinements. (Warning: I am using the term “refinement” in its 
common object-oriented (00) usage, namely to elaborate or extend. In contrast, “re- 
finement” has a different meaning in algebraic specifications - it means to elaborate 
but not extend a program’s functionality. “Extension” is a more appropriate term. 
Henceforth, I use the term “extension”, but beware that papers on FOP use the term 
“refinement” instead). 

A GenVoca model of a domain is a set of operators that defines an algebra. Each 
operator implements a feature. We write: 

M = { f, h, i, j } 

to mean model M has operators (or features) f , h, i, and j . One or more of these op- 
erators are constants that represent base programs: 

f //an application with feature f 

h //an application with feature h 
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The remaining operators ate functions which represent program extensions: 

i (x) // adds feature i to application x 

j (x) // adds feature j to application x 

The design of an application is a named expression called an equation : 

appl = i(f) // application with features i and f 

app2 = j (h) // application with features j and h 

app3 = i ( j (h )) // application with features i,j,h 

The family of programs that can be created from a model is its product-line. To 
simplify notation, we henceforth write i (j (h) ) as i*j*h, where • denotes function 
composition. 

A GenVoca expression represents the design of a program. Such expressions (and 
hence program designs) can be automatically optimized. This is possible because a 
function represents both a feature and its implementation. That is, there can be differ- 
ent functions with different implementations of the same feature. For example, sup- 
pose function k i adds feature k with implementation #1 to its input program, while 
function k 7 adds feature k with implementation #2. When an application requires the 
use of feature k, it is a problem of expression optimization to determine which imple- 
mentation of k is best (e.g., provides the best performance). Of course, more compli- 
cated rewrite rules can be used. Thus, it is possible to design efficient software auto- 
matically (i.e., find an expression that optimizes some criteria) given a set of 
declarative constraints for a target application. An example of this kind of automated 
reasoning - which is exactly the counterpart to relational query optimization - is [6]. 

The program synthesis paradigm of GenVoca is straightforward. Figure 1 depicts a 
program P that is a package of four classes (classl-class4). These classes are syn- 
thesized by composing features X, Y, and Z. X encapsulates a fragment of classl- 
class3, which is shown in a solid color. Y extends classl-class3 and introduces 
class4, which is shown in horizontal stripes. Z extends all four classes, and is shown 
in checker-board. Thus features encapsulate fragments of classes. Composing features 
yields packages of fully-formed classes. 

dassl dass2 dass3 dass4 

featureX 
featureY 
faalureZ 



Fig. 1. Package P = Z»Y»X 




My colleagues and I have had considerable success using GenVoca for creating 
product-lines for database systems [7], network protocols [7], data structures [6], 
avionics [2], extensible Java and Scheme compilers [3, 10], and program verification 
tools [13]. The next section briefly explains how code synthesis is performed. 



3.1 Implementation Details 

Extension and composition are very general concepts that can be implemented in 
many different ways. The core approach relies on inheritance to express method and 
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class extensions. Figure 2a shows method A() whose body sequentially executes 
statements x, y, and z. Figure 2b declares an extension of this method to be Su- 
per.AO followed by statement w. Super. A () says invoke the method’s original 
definition. The composite method is Figure 2c; it was produced by substitution (a.k.a. 
macro-expansion): that is, Super . A ( ) was replaced with the original body of A ( ) . 





void A ( ) { 




void A ( ) { 




void A ( ) { 




x; y; z; 




Super.A(); w; 




x; y; z; w; 


(a) 


} 


(b) 


} 


(c) 


} 



Fig. 2. Method Definition and Extension 



Class extensions are similarly familiar. Figure 3a shows a class P that has three 
members: methods A ( ) , B ( ) , and data member C. Figure 3b shows an extension of P, 
which encapsulates extensions to methods A ( ) and B ( ) and adds a new data member 
D. The composition of the base class and extension is Figure 3c: composite methods 
A ( ) and B ( ) are present, plus the remaining members of the base and extension. 



class p { 

void A ( ) {x;y;z;w;} 
void B ( ) (q; r ; t; } 
int C; 

String D; 

) (C) 



One way to implement the above is to use subclassing: that is, make Figure 3b a 
subclass of Figure 3a, where the semantics of the subclass equals that of Figure 3c. 
Another way is to use substitution (in-place modification) as we have illustrated. 
There are many other ways to realize these ideas with or without inheritance. 



class P { 




refines class P { 


void AO 1 x ; y ; z ; } 




void A ( ) { Super. A();w; } 


void B ( ) { r ; t; } 




void B(){ q; Super . B ( ) ; } 


int C; 




String D; 


> (a) 




> (b) 



Fig. 3. Method Definition and Extension 



4 AHEAD 



Algebraic Hierarchical Equations for Application Design (AHEAD) is the successor 
to GenVoca [3]. It embodies ideas that have revolutionized my thinking on program 
synthesis. In particular, AHEAD shows how step-wise development scales to the 
synthesis of multiple programs and multiple representations, and that software design 
has an elegant algebraic structure that is expressible as nested sets of expressions. The 
following sketches the basic ideas of AHEAD. 



4.1 Multiple Program Representations 

Generating code for individual programs is not sufficient. Today’s systems are not 
individual programs but groups of collaborating programs such as client-servers and 
tool suites of integrated development environments. Further, systems themselves are 
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not solely defined by source code. Architects routinely use many knowledge represen- 
tations to express a system’s design, such as process models, UML models, makefiles, 
or formal specifications. 

That a program has many representations is reminiscent of Platonic forms. That is, 
a program is a form. Shining a light on this program casts a shadow that defines a 
representation of that program in a particular language. Different light positions cast 
different shadows, exposing different details or representations of that program. For 
example, one shadow might reveal a program’s representation in Java, while another 
an FITML document (which might be the program’s design document). There are 
class file or binary representations of a program, makefile representations, perform- 
ance models, and so on. A program should encapsulate all of its artifacts or projec- 
tions. 

In general, suppose program P encapsulates artifacts A ; , , B , and C p , where the 
meaning of these artifacts is uninterpreted. I express this relationship algebraically as: 

p = { V V C P } 

where set notation denotes encapsulation. Members of a set are called units. 



4.2 Generalize Extensions 

Adding a new feature to a program may change any or all of its representations. For 
example, if a new feature F is added to program P, one would expect changes in p’s 
code (to implement F), documentation (to document F), makefiles (to build F), formal 
properties (to characterize F), performance models (to profile F), and so on. 

In general, suppose feature F changes artifacts A and B (where Ay and By denote the 
specifications of these changes) and adds new artifact D / . I say F encapsulates Ay, B ( , 
and Dy, and write this relationship algebraically as: 

F = {Ay, By, Dy } 



4.3 Generalize Composition 

Given P and F, how is F*P computed? The answer: composition is governed by rules 
of inheritance. Namely, all units of the parent (inner or right-hand-side) feature are 
inherited by the child (outer or left-hand-side) feature. Further, units with the same 
name (ignoring subscripts) are composed pairwise with the parent term as the inner 
term: 

F*P = { Ay, By, Dy } • { A p , B p , C p } 

= { Ay • A p , By • B p , C p , Dy } (1) 

Stated another way, F*P is computed by composing corresponding artifacts and the 
correspondence is made by name. Thus, the A artifact of F*P is produced by Ay*A ;) - 
the original artifact A p extended by Ay. Similarly, the B artifact of F*P is By *B^ - the 
original artifact B extended by By. Artifacts C and D of F*P correspond to their origi- 
nal definitions. (1) defines the Law of Composition: it tells us how composition dis- 
tributes over encapsulation. 
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Readers may recognize Figure 3 to be a particular example of this law. P is the 
base class of Figure 3a, encapsulating members A, B, and C. F is the class extension of 
Figure 3b, encapsulating members A, B, and D. The composition F*P - an illustration 
of (1) - is Figure 3c. More on this in the next section. 

You will see shortly that the Law of Composition applies at all levels of abstraction 
and can be made to apply to all artifacts. Figure 4 is an example of the latter. Fig- 
ure 4a is a grammar of a language that sums integers. Figure 4b shows a grammar 
extension that adds the minus operation. In particular, a new token MINUS is added to 
the grammar and the Operator production is extended with the MINUS rule. (The 
phrase Super. Operator says substitute the right-hand- side of the original Opera- 
tor production). Figure 4b shows the composite grammar. Each token and production 
corresponds to individual terms in the Law of Composition. 



// INTEGER is predefined 




MINUS 


" + " PLUS 




"+" PLUS 


Expr 




Expr 

: Val 


; Val 

| Val Operator Expr 




| Val Operator Expr 


• 




MINUS 






val 

: INTEGER 




Operator 

: Super .Operator 




Operator 

: PLUS 
| MINUS 


? 




| MINUS 






Operator 




' 




Val 


: PLUS 








: INTEGER 


(a) constant 




(b) function 




(c) composition 



Fig. 4. Grammars, Extensions, and Composition 



4.4 Generalize Modularity 

A module is a containment hierarchy of related artifacts. Figure 5a shows that a class 
is a 2-level containment hierarchy that encapsulates a set of methods and fields. An 
interface is also a 2-level containment hierarchy that encapsulates a set of methods 
and constants. A package is a 3-level containment hierarchy encapsulating a set of 
classes and interfaces. A J2EE EAR file is a 4-level hierarchy that encapsulates a set 
of packages, deployment descriptors, and F1TML files. 

In general, a module hierarchy can be of arbitrary depth and can contain arbitrary 
artifacts. This enables us to define a module that encapsulates multiple programs. 
Figure 5b shows a system to encapsulate two programs, a client and a server. Both 
programs have code, UML, and HTML representations with sub-representations (e.g., 
code has Java files and binary class files, UML has state machines and class 
diagrams). Thus, a module allows us to encapsulate all needed representations of a 
system. 

Module hierarchies have simple algebraic representations as nested sets of 
constants and functions. Figure 6a shows package K to encapsulate classl and 
class2, classl encapsulates method mthl and field fldl. class2 encapsulates 
mth2 and mth3. The corresponding set notation is shown in Figure 6b. 
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(a) 



J2EE EAR File 




(b) 



system 




code UML HTML code UML HTML 

/ \ I I ./ \ I I 

“.java, '.class state-machines Mitml '.java, ' class class diagrams Thtml 
Fig. 5. Modules are Containment Hierarchies 



package K 






K = { classl, class2 } 


class 1 class2 


classl = { mthl, fldl } 


/\ /\ 


class2 = { mth2, mth3 ) 


mthl fldl mth2 mth3 




la) graphical 


(h) algebraic 



Fig. 6. Modules and Nested Sets 



4.5 Generalize GenVoca 

A GenVoca model is a set of constants and functions. An AHEAD model is also a set 
of constants and functions, but now a constant represents a hierarchy that encapsulates 
the representations of a base program. An AHEAD function is a hierarchy of exten- 
sions - that is, it is a containment hierarchy that can add new artifacts (e.g., new Java 
and HTML files), and can also refine/extend existing artifacts. When features are 
composed, corresponding program representations are composed. If the representa- 
tions of each feature are consistent, then their composition is consistent. Thus 
consistent representations of programs can be synthesized though composition; this is 
exactly what is needed. 



4.6 Implementation Details 

We implement module hierarchies as directory hierarchies. Figure 7a shows our alge- 
braic representation of a module, and Figure 7b shows its directory representation. 
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(a) A = ( Code, R.drc, Htm } 
Code = ( X . j ava , Y . j ava } 
Htm = I W.htm, Z.htm } 



A 




Fig. 7. Corresponding Algebraic and Directory Representations 



Feature composition is directory composition. That is, when features are comp- 
osed, their corresponding directories are folded together to produce a directory whose 
structure is isomorphic to the feature directories that were composed. For example, 
the X . j ava file of C = B*A in Figure 8 is produced by composing the corresponding 
X . j ava files of B and A. 



B 



C°d e J |=] Htm 

A — A 
0 B BB 

X.javaY.java W.htm Z.htm 




Fig. 8. Composition of Feature Directories 



Our implementation is driven by purely algebraic manipulation. We evaluate an 
expression by alternately expanding nonterminals and applying the Law of Composi- 
tion: 

C = B • A 

= { Code fi , R.drc B , Htm fi } • { Code A , R.drc A , Htm A } 

= { Code B *Code A , R . drCg*R . drc A , Htm B *Htm A } 

= { X.java B , Y . j ava g }•{ X.java A , Y.java A }, 

R.drc B *R.drc A , { W.htnig } • { Z.htm A } } 

= { { X . j ava B *X . j ava A , Y . j ava fi *Y . j ava A } , 

R.drc B *R.drc A , { W.htm B , Z.htm A }} 

The result is a nested set of expressions. Each expression tells us how to synthesize 
an artifact of the target system. That is, the X . j ava artifact of feature C is computed 
by X. java fi *X. java ( ; the Y. java artifact of C is computed by Y . j ava B *Y . j ava A , 
the R . drc artifact of C is computed by R . drc /; »R . drc A , and so on. Thus, there is a 
simple interpretation for every computed expression, and there is a direct mapping of 
the nested set of expressions to the directory that is synthesized. 
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-r 
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& optimization 
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Fig. 9. Program Synthesis Paradigm of AHEAD 



Figure 9 illustrates the AHEAD paradigm. An engineer defines a system by 
declaratively specifying the features it is to have, typically using some GUI-based 
DSL. The DSL compiler translates the specification into an AHEAD expression. This 
expression is then expanded and optimized, producing a nested set of expressions. 
Each expression is typed - expressions that synthesize Java files are distinguishable 
from expressions that synthesize grammar files - and is submitted to a type-specific 
generator to synthesize that artifact. The set of artifacts produced are consistent with 
respect to the original declarative specification. AHEAD is a generalization of the 
Relational Query Optimization paradigm. 

A common question that is asked is: can you realistically design features so that 
they can be composed? Absolutely. It’s easy - this is what software product-lines are 
all about. Features or components are designed to be composable and compatible. 
Composability and compatibility are properties that don’t happen by magic or by 
accident; they are premeditated. Some of you may recall the old chip catalogs of the 
early 1970s, where all the chips in the catalog were designed to be compatible - they 
worked off of the same voltage, impedance, etc. Chips built by another manufacturer 
often were not compatible. A more familiar example today are disks for PCs. There 
are all sorts of disk manufacturers now that have an incredible line of products. These 
disks are compatible because they meet SCSI or IDE standards. (Recall that prior to 
plug-and-play standards, adding a disk to a PC required a high-paid technician to do 
the installation). The same ideas apply to software. 



5 Cultural Enrichment 

It is beyond the scope of this paper to show a detailed example of these ideas in 
action. For those interested, please consult [4]. In this section, I explain a simple 
result that illustrates AHEAD algebras and an elementary optimization. Then I 
discuss the breadth of the AHEAD framework. 



5.1 A Simple Result 

Have you ever wondered what an algebraic justification of object-oriented sub- 
classing (e.g., inheritance) would be and why inheritance is fundamental to software 
designs? Here’s an answer: when a program is synthesized, an expression is generated 
for every class of that program. Suppose the program has classes A, B, and C with the 
following expressions: 
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A=Z*Y*X*W 
B = Q*Y*X*W 
C=E*Y*X*W 

Observe that all three classes share a common sub-expression Y«X»W. Instead of 
redundantly evaluating this expression, one can eliminate common sub-expressions 
by factoring: 

F = Y • X • w 
A = Z • F 
B = Q • F 
C = E • F 

Whenever a new equation F is created, a new class F is generated. The relationship 
between classes F and A, B, C is indicated in the revised expressions: the expressions 
for A, B, C reference and thus extend F. Code generators materialize F as a class with 
A, B, and C as subclasses. That is, F contains the data members and methods that are 
common to its subclasses. Just as common sub-expression elimination is fundamental 
to algebra, inheritance hierarchies are fundamental to object-oriented designs, 
because they are manifestations of the same concept. Interestingly, the process of 
promoting common methods and data members of subclasses into a superclass is 
called refactoring in OO parlance, whereas in algebra it is called factoring. Not only 
are the concepts identical, the names are almost identical too. 



5.2 Even More Generality 

I have concentrated so far on domain-specific operators - constants and functions - 
whose compositions define programs within a target domain. But there are many 
operators in the AHEAD universe that are not domain- specific. I illustrate some with 
an example. 

In the current implementation of AHEAD, all code is written in lava that has been 
extended with refinement constructs (e.g., “refines” and “Super”). This language 
is called Jak (short for “Jakarta”). To compile these classes, the Jak files are translated 
to their Java file equivalents using the jak2java tool. Next, the Java files are 
translated to class files using the javac tool. These are derivation steps that can be 
expressed algebraically: Let P be a program that is synthesized from some AHEAD 
equation. P encapsulates a set of Jak files. Let P' define the set that additionally 
contains the corresponding Java and class files. The relationship of P and P' is 
expressed as: 

P' = javac ( jak2java( P ) ) (2) 

That is, the jak2java tool is an operator that elaborates or extends containment 
hierarchies by translating every Jak file to its corresponding Java file. Similarly, the 
j avac tool is an operator that elaborates containment hierarchies by translating every 
Java file to its corresponding class file(s). 

There are many other operators on containment hierarchies, such as j avadoc (that 
derives HTML-documentation files from Java files), javacc (that derives Java files 
that implement a parser from.jj files), and jar (a Java archive utility). In short, com- 
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mon tools that programmers use today are operators that derive and thus add new rep- 
resentations to containment hierarchies. Readers will recognize equation (2) to be an 
algebraic specification of a makefile. It is much easier to write and understand (2) 
than its corresponding ant declaration in XML. Thus, it should be possible to 
generate low-level makefiles from equational specifications like (2). Further, if the 
makefile expression is particularly complicated, it may be possible also to optimize 
the expression automatically (e.g., perform javac operator before javadoc) prior to 
makefile generation. Doing so would further relieve programmers of the burden of 
manually writing and optimizing these files. 

Software design involves many activities that involves many representations of a 
program (e.g., analysis, implementation, description). Given the ability to compose 
and derive, you can do just about anything. AHEAD unifies these activities in an 
algebraic setting. Not only will this simply program specifications, it will also make 
specifications more amenable to automatic optimization. 



6 Why Does AHEAD Work? 

I’m sure that some of you, upon reading this paper, will wonder what the big deal is; 
the ideas are straight from an introductory computer science course (a.k.a. “CS 101”). 
You are right about the simplicity, but you may have forgotten the state (and abject 
lack) of science in software design (e.g.. Section 2). As computer scientists we under- 
stand CS 101 concepts, but I claim that we do not know how they are applied to soft- 
ware design. Software engineers do not think about software designs in terms of 
algebras or anything (as far as I can tell) dealing with mathematics. They certainly do 
not think of design in terms of automation. Their reward structure for software devel- 
opment is also screwed up: complexity is appreciated; simplicity and elegance are dis- 
missed. Not only is this bad science, this is bad engineering. 

My students and I have synthesized the AHEAD tool suite, which is in excess of 
250K Java LOC, from elementary equational specifications. We know of no technical 
limit on the size of system that can be synthesized. The obvious questions are: why 
can AHEAD be this simple? What are we giving up? And why does it work as well as 
it does? 

There are many answers; here is one. I have seen the following idea proposed by 
different people in three consecutive decades, starting in late 1970s. Suppose a pair of 
independently written packages Q and R are to be composed. Composition is accom- 
plished in the following way: corresponding classes in Q and R are identified. That is, 
class X in Q corresponds to class Y in R, and so on for every relevant class. Then corre- 
sponding methods are paired. That is, method M in class X of Q corresponds to method 
N in class Y of R, and so on for all relevant methods. And finally, corresponding 
parameters are matched: parameter 2 of method M in class X of Q corresponds to 
parameter 3 of method N in class Y of R, etc. Given these relationships, tools can be 
built to compose Q and R, and examples can show that indeed a package with the 
functionalities of Q and R can be created. 

This approach has many problems. First, it does not scale in general. What happens 
if Q and R both have 1000 classes, 10,000 methods, and 20,000 parameters? Who can 
define (or have the patience to define) the required correspondences? How does one 
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validate these correspondences? Note the hidden complexity of this approach: every 
concept (class, method, parameter) has two names: the name used in package Q and 
that used in R. This means that programmers have to remember twice the amount of 
information than they need to. If k additional packages are to be composed, then pro- 
grammers must know k different names for the same concept. The concept is the 
essence of this problem; the different arbitrary names add accidental complexity [8]. 
In general, programmers have a hard time remembering all these accidental details. 

Second, it does not work in general. Just because the names in packages can be 
aligned syntactically does not imply semantic alignment. That is, there is no guarantee 
that corresponding methods agree on their semantics. If there is disagreement, this 
approach to composition and software synthesis fails. The only recourse is to define 
an adaptor that performs the semantic translation - if in fact such an adaptor can be 
written. 

In my experience, software reuse and software composition succeeds because of a 
premeditated design. Stated another way, components are composable only if they 
were designed with the other in mind. This axiom is crucial to scalability. It is very 
easy (and wrong) to assume that just because a small example works where this 
axiom does not hold, more complicated examples will work just as well. 

AHEAD’s contribution is basic: it shows how simple ideas and common software 
development tools can be unified and elegantly captured as an algebra that expresses 
the essential tasks of software design and scalable software generation as mathema- 
tics. I reject axioms that accept accidental complexity as fundamental. As a conse- 
quence, AHEAD provides a clean solution to a core design problem where class, 
method, and parameter names are standardized, and so too are their semantics. This 
enables us to build simple tools and attack problems of automated design on scale. 
Our work relies on a common engineering technique: arbitrary and random 
complexity are eliminated by design. AHEAD does indeed have correspondence 
mappings; they are implicit, and hence easy to write and easy to understand 2 . 

The following quote from Fred Brooke’s 1987 “No Silver Bullet” paper [8] helps 
to put the above arguments into context: 

The complexity of software is an essential property. Descriptions of software that 
abstract away its complexity often abstract away its essence... 3 Software people are not 
alone in facing complexity. Physicists deal with terribly complex objects even at the 
“fundamental” particle level. The physicist labors on in a firm faith that there are unify- 
ing principles to be found . . . Einstein argued that there must be simplified explanations 
of nature, because God is not capricious or arbitrary. 

No such faith comforts the software engineer. Much of the complexity that he must 
master is arbitrary complexity, forced without rhyme or reason, because they were 
designed by different people, rather than by God. 

Not quite. Just like physicists, I too believe there is an underlying simplicity in 
software. Programmers are geniuses in making simple things look complicated. If 
software were truly complicated, people could not program and architects could not 
design. There must be an underlying simplicity. The challenge is not making things 



Our belief is that once the core problems are understood, one can begin to relax 
assumptions within the AHEAD framework itself to address progressively broader design 
problems. 

3 The exception, of course, is modularity; hiding the details is what modularity is all about. 
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complicated, but revealing their essential simplicity. That is what AHEAD does and 
this is why it scales. 

Further, it does not take God to eliminate complexity. All it requires is common 
sense and the use of common engineering techniques. This has worked for many non- 
software domains; I and others are showing that it can work for software as well. 



7 Conclusions 

Just as the structure of matter is fundamental to chemistry and physics, so too must 
the structure of software be fundamental to Computer Science. By structure, I mean: 
What are modules? And how are modules composed to build larger modules? 
Unfortunately, the structure of software is not yet well-understood. Software design, 
which is the process to define the structure of an application, is an art. As long as it 
remains an art, our abilities to automate software design and make software develop- 
ment a true engineering discipline are limited. 

In short, software design is in desperate need for a science of design. Such a 
science, I have argued, must be intimately related to automated design. That is, a 
science of software design will not arise from having virtuoso engineers use their 
creativity and craftsmanship to create one-of-a-kind products. A science of design 
must arise from domains where the software development process is mature or 
reasonably well-understood and where developers can mechanize the process of 
creating successive variants of programs. Because today’s models of software design 
are not aimed at automation, progress towards a science is understandably lacking. 

I believe a science of software design is indeed possible, and have argued that the 
seminal work on Relational Query Optimization (RQO) is a powerful paradigm that 
can be emulated in other domains. RQO showed how declarative specifications can be 
translated into efficient query evaluation programs automatically. The core reason 
why RQO was successful is because it expressed the design of query evaluation 
programs algebraically. I presented FOP as a generalization of the RQO paradigm. I 
believe FOP could be a basis for a science of software design for many reasons: 

• it raises the level of modularity from “code” to “design-related-artifacts”, 

• program design and optimization are expressed algebraically (and thus are ideal 
for automatic manipulation), 

• it allows us to reason about applications in terms of their features (as architects 
do), and 

• it is based on a few simple ideas whose applicability shows no apparent bounds. 

Historically, science has progressed by leaps of intuition followed by many years 
of community debate before the real contributions of a work are understood. The 
science of software design will be no different; such a science is indeed years away. 
AHEAD has the right “look and feel” for particular aspects of software design, but 
that is a far cry from having the software development community accept and 
appreciate its possibilities. FOP does seem to be a step in the right directions of 
simplicity, mathematical elegance, and support for automation. These criteria, more 
than anything else, are the metrics by which advances in software design should be 
measured. 
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Abstract. In this talk we will discuss some logical foundations for the 
semantics of state-based system specifications. In particular we will dis- 
cuss the need for both: 

— a “glass box view” corresponding to the implementor’s contract. In 
this case the underlying paradigm is that the semantics of a spec- 
ification should be as loose as possible in order to capture all its 
correct realizations. 

— a “black box view” corresponding to the user point of view, and in 
particular to the properties the user of a realization of a specification 
can observe or rely upon. 

Of course both views should be formally related, and we will explain how 
this can be done by means of appropriate institution morphisms. 

If time permits we will also consider how these ideas could be extended 
to specifications of object-oriented systems. 
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1 Introduction 

It is very natural to reason about concurrent, communicating systems using 
model-checking techniques. But, it is not possible to show, by model-checking, 
that results scale to systems of arbitrary size. Namely, you cannot use model- 
checking techniques to prove results about about infinite families of about net- 
works of arbitrary size: this is the parameterised model checking problem (PMCP) 
which is, in general undecidable [1]. 

But in some subclasses of systems PMCP is decidable. We consider two in- 
teresting subclasses: proving indexed safety properties by abstraction, and unin- 
dexed liveness properties by induction. The latter is suitable when the individual 
processes degenerate. In both cases we develop some general techniques for state 
based specification with asynchronous communication, and then illustrate the 
techniques with a number of examples using the specification language Promela 
and the model-checker Spin. We discuss under what circumstances these ap- 
proaches are tractable, and speculate how the techniques can be extended to 
encompass larger (sub)classes of systems. 
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This abstract provides some background information about the electronic voting exper- 
iment that is planned in the Netherlands for the European Elections of 2004, and about 
our own involvement in the infrastructure for this experiment. The talk will elaborate 
further about the computer security issues involved, especially with respect to the use 
of formal methods for vote counting software. 

Remote Voting 

Since the late 1990s voting in the Netherlands proceeds largely via voting machines. 
These are dedicated computers that record and store votes. These machines are under 
control of local governments, who put them up in voting stations on election days. These 
voting machines (and all new versions of them) have undergone independent evaluation 
before being admitted. However the internal mechanics is secret. Also, the evaluation 
reports are not public. Nevertheless, at the time of introduction, these machines were 
uncontroversial. They have been used in several elections, without causing problems. 
Currently, such machines are the subject of much discussion, see for instance [2], 

In 2002 the parliament of the Netherlands adopted a temporary law that went a step 
further than voting via computers at voting stations. The law allows experimentation 
with what is called location-independent voting. It has resulted in plans to allow voting 
via internet and phone in the 2004 elections for the European Parliament. This involves a 
one-time, limited experiment, largely intended to explore the possibilities and to gather 
experience with the required techniques and procedures. 

Low-Tech Approach 

These electronic elections are set up for expatriats. They already have the possibility 
to participate in elections via voting by (ordinary) mail. To keep things simple, the 
approach in the electronic elections is modeled after this voting by mail. Hence, par- 
ticipants in the electronic elections are required to register explicitly in advance. Upon 
registration, they have to submit a copy of their pasport and provide a self-chosen pin- 
code, for authentication. 

The whole organisation is fairly low-tech, and involves various codes for voter iden- 
tification & authentication, and for candidate selection. In total, thousand different bal- 
lots (with different candidate codes) will be distributed randomly, in order to ensure 
confidentiality. 
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The complicated registration procedure thus prevents national adoption of this ap- 
proach. And because there is no national electronic identity card (yet), more high tech, 
crypto-based authentication procedures are not an option. 

Organisation 

The plans for these electronic elections have been elaborated by the Ministry of Inter- 
nal Affairs, mostly in 2003. There has been an open bidding to build the software for 
these elections, and to run it as a service. This bidding has been won by LogicaCMG. 
Also, a panel of independent experts has been set-up, for feedback. The main advice 
from this panel 1 was to run the project as open as possible, and to compartimentalise it 
maximally, so that fraud is difficult without cooperation of several parties. The Ministry 
owns the copyright on the software, and organises its own evaluations - again by sev- 
eral parties. For instance, our group has participated in an evaluation of the robustness 
of the webservers, during an experiment in nov. 2003. Also, the intention is to make the 
source code available for inspection 2 , but it will probably not appear on the internet, 
like earlier in Australia 3 . 

Vote Counting 

Late into the project the Ministry decided to open another separate, much smaller bid 
for the counting of the votes. It has been won by our group, on the basis of a pro- 
posal that involves annotating the Java source code with correctness assertions from the 
Java Modeling Language JML [1], These annotations are checked both with the run- 
time assertion checker [4] and with the newest version of the Extended Static Checker, 
ESC/Java 2 [3], developed in part by our group. Details will be in the talk. 
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In the last decade or so the subject of agent technology has been getting an ever 
increasing interest in both the fields of software engineering and artificial intelli- 
gence [17]. (Intelligent) agents are software (or hardware) entities that display a 
certain degree of autonomy while operating in an environment (possibly inhab- 
ited by other agents) that is not completely known by the agent and typically 
is changing constantly. Agents possess properties like reactiveness , proactiveness 
and social behavior, often thought of as being brought about by mental or cog- 
nitive attitudes involving knowledge, beliefs, desires, goals, intentions,..., in the 
literature often referred to as l BDI attitudes’ (for beliefs, desires, intentions). 

The concept of an autonomous agent is especially important if the agent 
is situated in an environment that is inhabited by other agents as well. This 
brings us to the study of multi-agent systems, which incorporates such issues 
as communication, coordination, negotiation and distributed reasoning/problem 
solving and task execution (e.g. distributed / cooperative planning and resource 
allocation). As such the area is part of the field of distributed AI. An important 
subfield is that of the investigation of agent communication languages that en- 
able agents to communicate with other agents in a standardized and high-level 
manner. Applications of agent technology are numerous (at least potentially), 
and range from intelligent personal assistants in various contexts to cognitive 
robots and e-commerce, for example [9]. 

Historically, after philosophical investigations into the essence of agency (in 
particular [2]) and several logical proposals of describing the behavior of intel- 
ligent agents (e.g. [4,12,8], researchers started investigating how these agents 
could be realized by means of special agent architectures and dedicated agent 
programming languages such as AGENT_0 ([16]). 

We think that especially the idea of developing special agent-oriented pro- 
gramming languages is very interesting and important since this enables us in 
principle to carry agent concepts through all the way from analysis via design to 
implementation. In this way one really can use the ‘cognitive’ concepts employed 
in the analysis also in the implementation since agent programming languages 
are equipped with these notions as well (without having to code these notions 
in some more or less ad hoc way!). That is to say, in theory, since in practice the 
match is not yet perfect (for instance, since some cognitive notions are lacking in 
AO programming languages). We believe that we should pursue what Slroham 
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has begun and aim for AO languages that possess the same notions as in the 
formal/logical descriptions of these agents. (We ourselves have recently extended 
our own language 3APL with the notion of declarative goal , which is generally 
missing in AO languages [6]). Although agent technology, and agent-oriented 
programming (AOP) in particular, thus is a very promising field, there are still 
a number of problems to be overcome, before it could really settle as an estab- 
lished programming paradigm like object orientation is nowadays! We mention 
a few other issues that should be dealt with. 

First of all, proposals for languages should come with a formal semantics in 
order to define language constructs in a precise and unambiguous manner. Our 
claim is that for this we should reuse concepts and techniques from ‘traditional’ 
programming as much as possible: e.g. we advocate the use of structural opera- 
tional semantics and notions and techniques from process algebra. Fortunately, 
there are already a number of papers going in this direction, e,g. [10, 11], apart 
from our own [7, 15]. 

Also the correctness issue should be taken more seriously. Multiagent systems 
are complicated, as all distributed systems, and to be sure the systems behave as 
they should, we must be able to verify their correctness in a formal analytical way. 
(In our view this, too, requires a formal semantics of the language(s) involved!) 
I believe the correctness issue for agents is still in its infancy. Interest in it is 
growing since one is getting to realize that it is needed to get reliable systems (cf. 
the initiative of NASA to enhance the study of formal methods for agent-based 
systems [13, 14]), but the subfield is certainly not as developed as for e.g. object- 
oriented programming (OOP). The correctness / verification / specification issue 
is of course also related to the gap observed in the literature between high-level 
specifications in agent logics on the one hand and the behavior of implemented 
practical systems on the other. 

Of course, also with respect to the issue of verification it would be unwise to 
start all over again: we should reuse a lot of theory and tools for non-agent pro- 
gramming styles (in particular OOP; we may think here of Hoare logic, dynamic 
logic and forms of temporal logic), but it is also clear that crucial adaptations are 
necessary if one wants to take typical agent-oriented notions such as, for exam- 
ple, BDI and autonomy for individual agents, and roles and normative behavior 
in agent societies into account as well, so that ideally ideas from traditional pro- 
gramming should be merged with the formalisms and logics that were especially 
devised for agents (e.g. BDI logic [12]). AOP is not simply an instance or slight 
variant of OOP...! AOP has its special features that have to be treated. Partic- 
ular attention should be given to relating the behavior of complex MASs and 
that of the constituent individual agents. More or less autonomous agents should 
be restrained within a MAS or agent society by norms enforced by (protocols 
within) institutions, for example. Implemented institution protocols should be 
proven correct with respect to the norms they are supposed to enforce. 

Finally, and perhaps most importantly, to guide users of the AOP paradigm 
we need a proper methodology for programming agents in which the typical 
aspects of agents are captured. Having an appropriate methodology for build- 
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ing agents falls within the area of agent-oriented software engineering (AOSE). 
Actually, AOSE has two quite distinct meanings: 

— the engineering of (general) software using agent concepts in analysis & 
design phases 

— the engineering of software written in an agent-oriented programming lan- 
guage 

We think the former is too ambitious and not feasible in general, while the 
latter is much more restricted and feasible with the advantage that one may hope 
to use similar concepts in the analysis, the design as well as the implementation 
of agents, as mentioned before (cf. [5]). We believe that “methodologies for MAS 
development should assist the developer in making decisions about those aspects 
of the analysis, design and implementation , that are critical for MASs, namely, 
social and cognitive concepts (e.g. norms and goals)” ([5]). Although a number 
of methodologies for AOP have been proposed in the literature (e.g. Gaia[18] 
and Tropos[3]), these still suffer from drawbacks and omissions, such as not sup- 
porting the implementation phase or not being usable for the important class of 
open systems in which agents may enter and leave the agent society. Therefore, 
in our view a truly agent-oriented approach is still called for! 
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Abstract. Software applications are inevitably concerned with data in- 
tegrity, whether the data is stored in a database, files, or program mem- 
ory. An integrity guard is code executed before a data update is per- 
formed. The guard returns “true” just if the update will preserve data 
integrity. The problem considered here is how integrity guards can be 
produced automatically from data integrity constraints. We seek a so- 
lution that can be applied in general programming contexts, and that 
leads to efficient integrity guards. In this paper we present a new integrity 
constraint language and guard generation algorithms that are based on 
a rich object data model. 



1 Introduction 

Every programmer understands the issue of data integrity. In database applica- 
tions, updates must be checked before they are applied to prevent data corrup- 
tion. In object-oriented programs, method parameters must be checked to ensure 
that object attributes are not corrupted. In networking, updates to configuration 
data and routing tables must be checked. 

Ideally, data integrity would be ensured in advance through program verifi- 
cation using static analysis, model checking, or theorem proving. However, large 
programs and unbounded data values are problematic for model checkers, while 
theorem provers generally require human guidance. More importantly, many 
programs accept data from the environment, and this data cannot be checked 
before run time, even in principle. An alternative to preventing bad updates is 
to monitor at run-time for the presence of corrupted data. An issue with this 
approach is how data that has been found to be corrupted can be “repaired” 
(see e.g., [1]). 

In this paper we focus on another run-time approach: the integrity guard. 
An integrity guard is a program that is executed just before a data update is 
performed. If the guard returns “true” then the update is guaranteed to cause 
no data corruption. It is desirable that a guard be exact - it should return 
true if and only if the update will not corrupt the data. A guard should also 
be efficient - it should not interfere with application performance requirements. 
Guards are often used with constraints that are invariants. When this is the 
case it is desirable that a guard be incremental : it can assume that prior to 
the update the data is valid. The guard generation problem is to automatically 
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generate an exact, incremental, and efficient guard from a data schema, a data 
update language, and set of data integrity constraints. 

Much work on the guard generation problem comes from the database com- 
munity, where it is known as the “integrity constraint maintenance problem”. 
A related and more general problem is “view maintenance” - recomputing the 
result of a query as the input data is updated. 

Our goal is to make guard generation useful for general-purpose program- 
ming. The database community has concentrated on the guard generation prob- 
lem primarily for the relational data model and for constraint languages whose 
expressiveness subsumes first-order logic (see Section 5 for details). However, 
common programming data structures can be hard to model relationally. And 
in a general programming context, we wish to generate imperative guards, not 
relational queries. Furthermore, guards generated from arbitrary first-order con- 
straints may have prohibitive execution cost. 

Our approach is to use an object data model in which program data struc- 
tures can be naturally expressed. We use an XPath-basecl constraint language 
that can express classical functional and inclusion dependencies and data restric- 
tion constraints, but with expressiveness limited enough to ensure that generated 
guards are inexpensive to evaluate (in particular, much less expensive than for 
traditional relational query languages). By using XPath we also gain in read- 
ability and user-familiarity. Finally, our architecture for guard generation allows 
guards to be produced for a wide range of data infrastructure. 

Thus the main contributions of our work are a) a constraint language that 
is expressive while having advantages for generation and evaluation of guards 
b) algorithms for generating low-cost guards and c) a modular implementation 
framework that allows guard generation in multiple data storage paradigms. 
The language and algorithms we describe have been implemented as part of the 
Delta-X system at Lucent. This system is used to generate production code in 
several complex network management applications. 

The paper is organized as follows. Section 2 presents our data model, up- 
date model, and constraint language, and gives properties of the constraints 
that will be useful in guard generation. Section 3 defines formally the incre- 
mental precondition problem in general, and presents the high-level structure 
of our procedures. Section 4 gives a detailed look at guard-generation. Section 
5 overviews related work and discusses the implementation and applications of 
the framework, including experience and open issues. 

2 Specifying Data Integrity 

In this section we present a simple object data model, a set of data update 
operations, and our language for expressing constraints. 

2.1 Data Model 

A data signature is a set A = {a\ . . . a n } of unary function symbols, where each 
symbol cq in A is either of integer type or node type, and a set Classes of class 
names. An tree t of this signature has the form 
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t = (nodes, class, I, child) 

where nodes is a finite set, class is a mapping from nodes to Classes, I is a 
function interpreting members of A of integer type as functions from nodes to 
the integers, and members of A of node type as functions from nodes to nodes. 
Function child maps each node n to a sequence mi . . . m.fc of distinct nodes, such 
that the binary relation defined by m £ child(n) forms a tree. For cq a symbol 
of A we define type(ai) to be the integers if a* has integer type, and nodes if at 
has node type. 

This data model is a simplified object model - nodes represent objects, func- 
tion symbols in A represent attributes, and members of Classes represent class 
names. The model is simplified in that our model captures only attributes of in- 
teger and pointer type. Also, we capture only a weak notion of class in our model, 
as all objects share the same set of attributes. The absence of an attribute in a 
class can be modeled through the use of distinguished attribute values. Finally, 
we do not model class inheritance. 

Running Example. Figure 1 shows an example tree that describes a network 
configuration for routing software in a telecommunication system. The tree repre- 
sents regions in the network, with attributes storing the minimum and maximum 
call capacity of each region and the children of a region representing the regions’ 
neighbors. In the figure each box represents an object, with the object’s class at 
the top and its attributes listed below. The system’s call-processing component 
reads this data in order to route calls, while the provisioning component updates 
the data in response to commands from a technician. 




Fig. 1 . Data for Running Example 



We provide two basic update operations on trees, each of which is parame- 
terized. A create operation Create(n, C, U) for tree t has as parameters a node 
n of t, a class name C of Classes, and elements U =< U\, . . . ,u n >, with each 
Ui in type(ai). The effect of applying Create(n,C,U ) to t is that a fresh node 
n' is added to nodes(t), function class is updated so that class(n') = C, each 
function ai is updated so that ai(n') = Ui, and function child is extended so that 
child(n) has additional, final element n'. A delete operation Delete(n, C) for t 
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has as parameters a leaf node n of t and a class name C of Classes. The effect 
of applying Delete{n, C) to t is that node n of class C is removed from nodesff). 



2.2 Constraint Language 

We present a two-tiered language, consisting of an expression language and an 
assertion language. The expression language allows one to define sets of nodes 
in a data tree, while the assertion language consists of statements about sets of 
nodes. 

Our expression language is based on XPath [ 5 ] , an XML standard that allows 
one to express queries on an XML document. Evaluating an XPath expression on 
a tree node yields a set of nodes, or a set of values, or a boolean. In Delta-X we use 
a simplified form of XPath having the following abstract syntax, where oc ranges 
over {=, <, <, >, >}, axis ranges over {4—, 4—*, —4, -4*, j, j* f, f*}, a ranges over 
attribute names, C ranges over class names, and k ranges over integers: 

E ::= e | / | @a | axis | C \ E\ U E2 \ [q] \ E1/E2 
q ::= E | E\ oc A2 | A oc k\ class = C | c/i A <72 | c/i V q2 

We now briefly describe, in the style of [ 20 ], the meaning of expressions by 
defining the set E(n) of nodes “returned” by expression E relative to a node 
n of tree t. Expression e returns {n}. Expression / returns the root node of t. 
Expression @a returns the singleton set containing the value of attribute a of n. 
Expression axis returns the nodes related to n by the axis (for example, j returns 
the children of a node, j* the descendants, and — ► the right siblings). Expression 
C returns the children in class C of a node. Expression E1UE2 returns the union 
of Ei(n) and E2(n). Expression [<7] returns {n} if qualifier q returns false, and 0 
otherwise. Expression Ei/E 2 returns the functional composition of E\ and E 2 
(in other words, the union of what E2 returns relative to each of the nodes in 
the set Ei denotes). 

A qualifier denotes a node predicate. Qualifier E holds of a node n in tree t 
iff E(n) is non-empty. Qualifier E\ oc E2 holds of n iff E\(n) contains an element 
ni and £2(^1) contains an element 712 such that 71 1 oc 712 . Similarly, E\ oc k holds 
of n iff Ei(n) contains an element ni such that n\ oc k. Qualifier class = C holds 
of n iff class{n ) = C. Qualifiers q\ A <72 and q\ V (72 provide logical conjunction 
and disjunction. 

Assertions are built up from expressions. Our assertion language supports 
three types of assertions (or “constraints”). A restriction constraint Never(E) 
asserts that for every node in a data tree, E returns empty on that node. 

A referential constraint Reference(E) : Source(E\ . . . E n ), Target(Fi . . . F n ) 
asserts that for every node n, such that E evaluated at the root satisfies 71, 
there is another node n' in the tree such that for each i, Ei(n) has nonempty 
intersection with Ej(?r'). 

A key constraint Key(E) : Fields(Fi . . . F n ) asserts that for any two distinct 
nodes n\,n,2 returned by E at the root of a data tree, there is some i such that 
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Fi(n 1 ) is distinct from Fi(n 2 ): that is, a node can be uniquely identified by the 
values of F \, . . . , F n . 

We write Lxp for the language obtained from this assertion language by 
taking expressions from XPatlr. Lxp allows one to express a wide range of 
program invariants. 

Example. Returning to the network configuration example, one can express 
that the minimum capacity of a region must be above the maximum capacity of 
adjacent regions by 

Never([class = Region A 

@minCpty < Adj Region / @regionI d / @maxCpty\) 

One can express that a region ID uniquely identifies a region node by 
Key(i* / Region) : Fields{@regionId) 

One can express that the region ID of every adjacent region points to some node 
ID of a region by 

Ref erence([* / Adj Region) : Source{@regionId), Target{@nodeId) 

Lx p is strictly more expressive then the standard key and referential constraints 
of relational and XML data. On the other hand, evaluation of the language is 
tractable: 

Theorem 1. The problem of evaluating a constraint <f> £ Lxp on a tree t can 
be solved in polynomial time in |^|, |i|, on a machine that can iterate through t 
with unit cost for each child, sibling, or parent navigation step. 

The proof follows from the fact that evaluating a XPatlr expression E can be 
done in time |£j|t| 2 . This quadratic bound requires a refinement of an argument 
in [8]. For now we sketch a simpler argument that gives a bound of |i?||f| , 
and which will be relevant to our later algorithms. An XPatlr expression can be 
translated in linear time to a first-order formula in which every subformula has 
at most three free variables. The evaluation of such formulae on data trees is well 
known to be in cubic time ([11]) using a bottom-up algorithm. The polynomial 
bounds now follow easily. A more detailed look at this translation and its target 
logic is presented in Section 4. 

A Lxp constraint is called local if the initial expression is of the form j* 
/ E, and all other expressions do not involve navigation of axes or following 
node-valued (i.e. pointer) attributes. The second and third example constraints 
above are local. For local constraints, we can get extremely efficient bounds on 
verification: linear for Never, quadratic for all others. 

3 Computing Guards from Integrity Constraints 

Imagine a system in which condition <f> currently holds and must continue to 
hold. To ensure that a state update will not take the system to a state not 
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satisfying <j J, we want to perform a check such that 1) the check will succeed iff 
applying the update would leave the system in a state satisfying <p, and 2) the 
check will be inexpensive to perform. We now formalize the problem of finding 
such a check. 

For simplicity we will for a moment treat preconditions in a purely semantic 
way. Assume a set S of states. Let op : S — > S be a state update operation 
and let <f> : S — > Bool be a state predicate. The weakest precondition [7] of <p 
and op , written wp(op, <f>), is the predicate that holds of s exactly when <p(op(s)) 
holds, for all s in S. A predicate ip is an incremental precondition of <p and op if 
<p(s) => (ip(s) <+> wp(op, <p)) holds for all s in S. In other words, ip is a predicate 
that acts like wp(op, <p) for all states in which <p holds. Trivially, wp(op, <p) is an 
incremental precondition for op and <p , and so is the predicate -«p V wp(op, <p). 
We are interested in incremental preconditions that can be evaluated cheaply, 
and generally we can expect no relationship between the logical strength of a 
predicate and its cost. For example, wp{op, <p) is not necessarily more costly than 
-><p V wp(op, <p). 

In putting these ideas into practice we need languages to describe updates 
and properties of states. In our case we actually need two property languages: a 
specification language in which to describe constraints, and an executable target 
language in which to describe incremental preconditions. Our computational 
problem is then: given a constraint in the specification language and an operator 
in the update language, compute a minimal cost incremental precondition in the 
target language. An issue is whether an incremental precondition exists in the 
target language for each constraint in the specification language (see [2]). 

In Delta-X the specification language is Lxp and the update language is 
the one defined in Section 2, consisting of create and delete operations. These 
updates have parameters that are instantiated at runtime; we want to generate 
incremental preconditions with the same parameters. 

In producing guards (i.e. incremental preconditions in an executable target 
language) from Lxp constraints, we work in multiple steps using intermediate 
languages. Delta-X supports several target language and environments (e.g. Java 
code storing objects within main memory, or C++ code storing objects within 
a relational database), so we translate constraints to guards via an intermedi- 
ate language named DIL. This language has the basic control structures of an 
imperative language plus data types based on our data model. 

Another intermediate language is called for because DIL is unsuited to the 
simplification of guards. We first produce the guards in a first-order logic on 
trees. This logic, called FOT, is powerful enough to express both the constraints 
of Lxp and the generated guards. The basic precondition generation algorithms 
are easy to express as transformations on FOT , and as a declarative language 
it provides a good framework for simplification. 

Hence we compute guards in four steps, as shown in Figure 2. We first trans- 
late a Lxp constraint (p into a formula ipo of FOT (see Section 4.1). Next we 
generate an incremental precondition of ipo within FOT , and then simplify to 
obtain formula ip\. In the next step we translate ip\ into a DIL program, which 
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is finally translated into a program in the target programming language. Before 
going into these steps in detail, we state some results about the algorithm as a 
whole. 




translate compute incremental translate to translate to 

to logic precondition generic language target language 

Fig. 2. Code-generation Scheme 



Theorem 2. For any Lxp constraint and any update operation, let ip be the 
result of the algorithm shown in Figure 2. 

— ip runs in time polynomial in the data ( where atomic operations of the target 
language are assumed to have unit cost). In fact, we can give the same bounds 
for ip as we can for evaluation of constraints in Theorem 1 - e.g. quadratic 
in |i| for Never constraints. 

— If cp is a local constraint, then ip can be evaluated in: constant time for a 
Never constraint, linear time for a Key constraint, and linear time for a 
Reference constraint for Create operations. 

On the other hand, there are limits to what one can hope to accomplish for 
any incremental precondition algorithm: 

Theorem 3. The problem of determining, given a (p in Lxp and an update 
operation, whether or not there is an incremental precondition of (p with a given 
quantifier rank, is undecidable. If (p consists of only Never constraints, then the 
problem is decidable but NP-Hard. 

The proof uses the undecidability of the implication problem for XML keys 
and foreign keys, the decidability of existential first-order logic over graphs, and 
the intractability of conjunctive query satisfaction. 

4 Algorithms 

4.1 Translating Constraints to Logic 

The first step of our translation is from Lxp constraints to FOT formulas. The 
syntax of FOT formulas and terms is as follows, where C ranges over Classes, 
k over integers, axis over {!, j*, j*, — — >*}, and oc over {=, <, <, >, >}: 

(p ::= \/x G C : <p \ 3x G C : <p \ (pi A <p 2 \ (pi V (p 2 \ (pi => (p 2 \ ~«P \ 
class(t) = C | ti axist 2 | h oc <2 
t ::= x | t.a \ k \ parent(t) 
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A formula is interpreted relative to an instance t as follows. The logical symbols 
have their expected meaning. Formula c lass(t) = C holds if t represents a node 
of class C. Formula t\ j t 2 holds if the node represented by t\ is a child of 
the node represented by t 2 . Other formulae of the form t\ axist 2 are interpreted 
similarly. For example, for axis J.*, t\ must be a descendent of t 2 , and for axis — 
t\ must be the right sibling of t 2 . Formula t\ = t 2 holds if the terms represent 
the same integer values or the same node values. Other formulae of the form 
ti oc t '2 are interpreted similarly. 

The term £ is a node variable, the term t.a represents the a attribute of 
the node represented by t, the term k represents integer value k , and the term 
parent(t ) represents the parent of the node represented by t. 

We translate a constraint in Lxp to a closed formula of FOT in two stages. 
First, the XPath expressions within the constraint are each translated into open 
formulas. Second, the constraint itself is translated, with the XPath-related for- 
mulas used as parameters. 

Example. The Never constraint of our running example translates to: 

\/x £ Region : \/y € Adj Region : y J. x => 

\/z £ Region y : regionld = z.nodeld => z.maxCpty < x.minCpty 

In translating an XPath expression to FOT , we obtain a formula containing 
free variables x and y. The formula represents a function from an input node x to 
an output node y. Because of space limitations we cannot present details of the 
translation. One issue is that an XPath expression can return nodes of different 
classes. Since our logic provides only for quantification over nodes of a single 
class, translation requires us to bound the set of classes in which a variable 
can occur. We do a static analysis to conservatively estimate which classes a 
particular variable may range over. The analysis can be made more precise in 
the presence of schema information, such as a DTD. 

This translation satisfies two properties. First, <f> has no subformula contain- 
ing more than three free variables. As explained in the proof of Theorem 1, this 
guarantees low evaluation complexity. Second, <j> has limited- alternation. This 
means that no universal quantifier is found within the scope of a existential 
quantifier, no negation symbols are present, and in an implication ipi — > i\> \ the 
formula ipi contains no universal quantifications and no implications. Precondi- 
tion algorithms are much simpler for this class. 

The translation of assertions is a straightforward implementation of the se- 
mantics. This translation produces formulas that are limited-alternation, while 
our translation of expressions produces formulas that are both limited-alterna- 
tion and within the three- variable fragment. 

4.2 Computing Incremental Preconditions 

We now present our incremental precondition algorithm, which accepts as input 
an update operation and a specification in FOT , and produces an incremental 
precondition as a formula of FOT . 
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fwp (op, 01 * 02 ) 
fwp (op,3x £ C : (j>) 
fwp ( op, 3 x £ D : <t>) 
fw P (op,\/x £ C : (f>) 
fw P (op,\/x £ D : <f>) 
fwp ( op,p | t) 
fwp (op, t l p) 
fwp ( op,p I* t) 
fwp (op,t l* p) 
fwp(op,t^> p) 
fwp (op, p -> t ) 
f wp (op, t->* p) 

fwp (op, p -> * t) 

fwp ( op, axis(ti,t 2 )) 

fwp (op,ti op t 2 ) 
fwp (op, t) 



= fwp(op,<j) l) * fwp (op, <p 2 ) (* a prop, connective) 

d = 3 x € C : fwp (op, 4>) V fwp (op, <j>[x/p]) 

d = 3 x£ D : fwp(op, 4>[x/p]) 

d = Vx £ C : fwp (op, cj>) A fwp (op, <t>[x/p]) 

d = V* € D : fw P (op, <j>[x/p\) 



def n , 

= false 

def' ... 

— nit 

def , 

= P = t 



def 



= t 



def n , 

= false 

def . 

= t in 

def . 

= P = t 

= f axis(ti,t 2 ) 

def 

= t\ Op 1 2 



' A Ad V* G D : (x ^ t A * | n) 



(ti ^ p) 



= t 



(t a term or boolean constant) 



t 



Fig. 3. Weakest Precondition Calculation for Operation op = Create(n, C, U) 



fw P (op,3x € C : 4>) = 3x & C : x n A f wp (op, <j>) 

fw P (op, 3x € D : <f>) d = 3x G D : f wp (op, 4>) 

fw P (op,Vx £ C : <f>) d = Vx G C : x =£ n =4> fw P (op,tp) 

fw P (op,Vx £ D : r/>) d = Vx £ D : f wp (op,<j>) 

Fig. 4. Weakest Precondition Calculation for Operation op = Delete(n, C) 



As a first step towards incremental precondition generation we have a sim- 
ple inductive algorithm f wp (op, <f>) that calculates a weakest precondition for 4> 
under op. Weakest preconditions can be thought of as a default case for incre- 
mental integrity checking. In fact, one can obtain an incremental precondition 
by computing f wp (op, <fi) and then simplifying, using (f> as an axiom. Instead, we 
begin with a set of rules that generate incremental checks directly, thus ensuring 
that the most important simplifications are performed. The algorithms for com- 
puting f wp (op,(f>) for Create and Delete operations are shown in Figures 3 and 
4. Only the cases that differ from those of Figure 3 are shown in Figure 4. We 
write <f>[x/p] for the formula obtained by substituting term p for free occurrences 
of variable x in </>. In the figures, p is a parameter for the created object, C the 
class of p and D an arbitrary class other than C. 

Figures 5 and 6 show the incremental precondition algorithms for Create and 
Delete operations. Again, the Delete case includes only rules differing from the 
Create case. These rules are valid for the limited-alternation fragment of FOT 
only. For example, in both the Create and Delete case we use the fact that since 
limited-alternation formulas are II 2 , there will be no universal quantifiers nested 
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A{op, 0 ) 

A{op, 3 x £ D \ (j>) 
A(op,\/x £ C : 0) 
A{op,Mx £ D : 0) 
A(op,</) i A 0 2 ) 
A(op, 01 V 02 ) 
Z\(op, 01 =>• 02 ) 
z\(op, 0) 



= true (0 does not contain c) 

= f true ( d any class, including c) 

d = Vi£C: A(op, 0) A fwp(op, <t>[x/p\) 

= V* € D : A(op, 0) 

= f A(op, 0l) A A(op, 02 ) 

def 

= (^(op,0i) A A(op,0 2 )) V fwp (op, 01 V 02 ) 

= f fwp{op, 01 ) =>• A(op, 02 ) 

= f 0 (0 atomic) 



Fig. 5. Incremental Precondition Calculation for Operation op = Create{n, C, U) 



A{op, 3x £ C : 0) 
A{op, 3x £ D : 0) 
A{op, V* £ C : 0) 
A(op,Vx £ D : 0) 
A(op, 01 => 02 ) 
CBF(op, 3x £ C : 0) 
CBF(op, 3x £ C : 0) 

CBF(op, 3x £ D : 0) 
CBF(op, 0i V 02) 
CBF{op, 0i A 02) 
CBF(op, 0) 



= CBF(op, 3x £ C : 0) =► Up {op, 0) 

= f true (d c) 

d = Vi 6 C : i ^ n A(op, 0) 

= f Mx £ D \ A{op,(j)) 

= f fwp{op, 0i ) =>■ zi(op,0 2 ) 

= 0[x/n] (c does not appear free in 0) 
d = (3x £ C : x ^ n A CBF{op, 0)) V CBF{op, <j>[x/n\) 
(c appears free in 0) 

= f 3 iGD: CBF{op, 0) 

= f CBF{op, 0i ) V CBF(op, 02 ) 

= f CBF(op, 0i ) V CBF{op, 0 2 ) 

*= f 0 (0 atomic) 



Fig. 6. Incremental Precondition Calculation for Operation op = Delete{n, C ) 



inside existential quantifiers. In the case for implication in Figure 5, we use that 
if 0 i => 02 , then 0i must contain only universal quantifiers. 

The algorithm for deletion uses an auxiliary function CBF{op, 0) (“can be- 
come false”), defined for every formula without universal quantifiers, which re- 
turns true whenever operation op can cause 0 to change from true to false. We 
present a basic algorithm for computing CanBecomeFalse, but algorithms based 
on more precise static analyses are possible. Indeed, much more precise, albeit 
ad-hoc, algorithms are used in our implementation. 

Example. In our example constraint, for the operation op of creating a new 
AdjRegion, the algorithm will produce the incremental precondition: 

Vx G Region, p [ x =$■ 

Vz G Region, p.regionld = z.nodeld => z.maxCpty < x.minCpty 

Theorem 4. Algorithm f wp {op,(J)) computes the weakest precondition of 0 and 
op, while algorithm A{op,(f>) computes an incremental precondition off) and op. 
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One can also verify that for local constraints the output of these algorithms 
meets the complexity bound of Theorem 2. For general constraints the claims we 
can make are weaker. First of all, there are cases where the logical complexity 
of an incremental precondition is higher than that of the original constraint. For 
example, in a constraint of the form 3a; £ C : <j), a delete operation Delete(n, C) 
may yield the precondition <f>(n ) => 3x G C : x n A(f>(x), which is logically more 
complex but should yield better performance in the “average case”. However, 
one can show that the worst-case running time for evaluation of the precondition 
can never be more than a constant factor above that for evaluation of the original 
constraint. This follows because f wp preserves the structure of formulas, hence 
preserves the running-time bounds, while the running time of A is at worst linear 
in that of f wp . 

4.3 Logical Simplification 

The Delta-X simplifier is a rewrite system that takes a formula of FOT as input 
and produces a logically equivalent formula of FOT as output. The quantifier 
depth and maximum number of free variables of subformulas does not increase 
through simplification. Indeed, because maximum quantifier depth is a factor 
that relates strongly to performance of the generated code, a main goal of sim- 
plification is to reduce quantifier depth. 

The rewrite rules of the simplifier are based on laws of first-order logic and 
the domain of trees. The following are a few sample rules: 

3x G A : (j)\ V (j >2 4>i V 3x G A : fa (x not free in fa ) (1) 

(x not free in t) (2) 

t J. x x = parentft) (3) 

Rule 1 captures a validity of first-order logic. Rule 2 is a demodulation rule, 
allowing one term to be substituted for an equal term. Rules 3 is domain-specific; 
it says that t is a child of x just when x is the parent of t. Additional rules 
would be present if schema information were available. For example, rules would 
capture the relationships given by a class hierarchy. 

Example. Figure 7 shows how our system simplifies the example precondition 
of Section 4.2. The subformula c lass(parent(p)) ^ Region could be simplified to 
false if schema information showed that the parent of p must be of class Region. 

To get a feeling for the cost savings achieved by the simplifier, we generated 
preconditions from the 83 constraints in the Delta-X regression test suite, which 
are modelled after constraints in Delta-X applications. The cost of a precondi- 
tion was computed as n d , where n is the number of nodes per class, and d is 
the maximum loop nesting depth in the code generated for the precondition. 
Assuming 1000 nodes/class, the cost before simplification was 9.6 x 10 6 , and the 
cost afterward was 3.5 x 10 6 - a savings of about 63%. Although the cost savings 
are good for this constraint set, the simplifier lacks robustness. We have had to 
make extensions to the rule set as new constraint examples appear. 
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V* £ Region : p | x =>• 

Vz £ Region : p.regionld = z.nodeld => z.maxCpty < x.minCpty 
Vx £ Region : -ip J, x V 

Vz £ Region : p.regionld ^ z.nodeld V z.maxCpty < x.minCpty 
Vx £ Region : parent[p) ^iV 

Vz £ Region : p.regionld ^ z.nodeld V z.maxCpty < x.minCpty 
V* £ Region : parent(p) x V 

Vz £ Region : p.regionld ^ z.nodeld V z.maxCpty < parent(p) .minCpty 
Vz £ Region : p.regionld ^ z.nodeld V z.maxCpty < par ent(p). minCpty V 

Vx £ Region : parent(p) ^ x 

V2 £ Region : p.regionld ^ z.nodeld V z.maxCpty < parent(p) .minCpty V 

c lass(parent(p)) ^ Region 

Fig. 7. Simplification of the Example Precondition 

Our rewriting system currently uses a bottom-up rewriting strategy. To in- 
crease the power of our system, we are experimenting with alternative rewriting 
strategies. We are also considering the use of third-party systems (e.g., Simplify 
[14], PVS [16]), but have yet to find a system that meets our needs. Most sys- 
tems are geared towards theorem proving rather than simplification (e.g., they 
use skolemization, which does not preserve logical equivalence). There are li- 
censing issues with most academic systems, and many commercial systems are 
targeted to special domains, such as hardware design. Finally, we require that 
simplification be directed by our cost function. 



4.4 Translating Logic to Code 

We translate formulas of our logic into code via the Delta-X Imperative Language 
(DIL). The translation of DIL to popular imperative languages is straightfor- 
ward, so here we describe only the translation from logic to DIL. 

DIL looks roughly like C++ and Java. It has classes, methods, statements, 
and expressions. The types, expressions, and basic statements of the language 
relate directly to the data model we use. For example, there are expressions to 
get the attribute of a node and to get the parent of a node. Sequencing, looping, 
and conditional statements are provided as control structures. However, only 
special-purpose looping statements are provided: for iterating over all objects of 
a class, or over all children of a node. 

The translation to DIL takes a formula of our logic, plus a boolean variable, 
and produces a statement such that the value assigned by the statement to the 
variable is exactly the value our semantics dictates for the formula. Terms are 
translated similarly, except that the computed value need not be boolean. 

Example. The following shows the DIL code produced from a formula similar 
to the simplified precondition of Figure 7. 

// forall z in Region: 

// p. region <> z.nodeld or z.maxCpty < parent (p) .minCpty 
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okay : = true 

for all z in Region while okay { 

// p. region <> z.nodeld or a.maxCpty < parent (p) .minCpty 
okay := p. region <> z.nodeld 
if ( ! (okay) ) { 

okay := a.maxCpty < parent (p) .minCpty 

} 

} 

The translation of logic to DIL works in a bottom-up fashion on the structure 
of the formula. The details are mostly straightforward, because most terms of 
the logic correspond closely to expressions of DIL. However, in the translation of 
quantifiers one can tradeoff space for time, so we define two translation methods. 
In the iterative method , a quantifier is translated directly to a loop construct of 
DIL , as in the example above. In the tabular method , a quantifier is translated 
to a mapping represented as a table. The mapping obtained from the universally 
quantified formula in the example above takes as input a value for free variable 
p, and produces a boolean value as output. 

The iterative translation method produces code that in the worst case re- 
quires dk space and n k time, where d is the maximum size of data values and 
Oin k ) time, n is the number of nodes in the tree, and k is the maximum quan- 
tifier depth of the formula. The tabular method produces code with worst case 
time and space 0(n v ), where v is the maximum number of free variables found 
in any subformula of the formula. 

5 Related Work and Discussion 

The relational data model is the basis of much work on integrity constraint 
maintenance. [15, 3] deal with a rich class of constraints on relational databases, 
with an emphasis on static verification of transformational programs. Runtime 
approaches using relational calculus (equivalent in expressiveness to first-order 
logic) as the specification language include [10,18,9]. [12] surveys the problem, 
dealing with questions such as which additional data structures are to be main- 
tained. [10] gives algorithms that can be used to provide a solution to the in- 
tegrity constraint maintenance problem for relational calculus. The maintenance 
of arbitrary first-order constraints is problematic because the evaluation of first- 
order formulas has PSPACE-complete combined complexity. For this reason the 
incremental evaluation of such powerful languages has not become a standard 
part of commercial database management systems. 

Richer than the relational model is the object data model, in which program 
data structures can be captured in a natural way. [13] studies constraint main- 
tenance within an object-oriented database, again using a language that can 
capture all first-order constraints. Due to the richness of the language [13] can- 
not provide efficient exact guards, and hence looks for ways to provide weaker 
guarantees. 

There is much recent work on the hierarchical XML data model, which lies 
in expressiveness between the relational and object models. XML constraint lan- 
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guages have evolved from DTDs, which express purely structural properties, to 
XML Schema [19], which extends DTDs with further structural features as well 
as the key and foreign key constraints of [4]. Yet more expressive languages [6] 
include both structural and data-oriented features. [17] presents integrity con- 
straint algorithms for a subset of XML Schema dealing only with the tree struc- 
ture, not with data values. To our knowledge no work on incremental constraint 
checking for more expressive XML constraint languages exists. 

The specification language of the Lucent version of Delta-X differs in sev- 
eral ways from the one presented here. The most significant difference is that 
node expressions allow just the child axis, and that only key constraints must 
be of the form Key(i* /C ) . . . for C a classname. On the other hand, Delta-X 
allows a generalization of Never constraints that restricts the cardinality of a 
node expression — Never asserts that this cardinality is 0; the general version 
allows any integer upper or lower bound. The production version can make use 
of schemas specifying for each class C the possible child classes. The Delta-X 
simplifier allows these additional constraints to be exploited in guard generation 
- the schema is read in along with the constraints, and a set of simplification 
rules are dynamically generated. The schema for these applications requires the 
class containment hierarchy to be acyclic, and hence implies a fixed bound on 
the depth of the object hierarchy. With this restriction the use of the descendant 
relation in constraints becomes unnecessary. The absence of sibling axes is due to 
the fact that in these data-oriented applications the sibling ordering is arbitrary. 
In addition to Create and Delete, Delta-X supports a Modify update operation 
on trees, which allows the modification of selected attribute values. 
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Abstract. Component adaptation is widely recognised to be one of the 
crucial problems in Component-Based Software Engineering. The objec- 
tive of this paper is to set a formal foundation for the adaptation of het- 
erogeneous components that present mismatching interaction behaviour. 
The proposed adaptation methodology relies on: (1) the inclusion of be- 
havioural types in component interfaces, to describe the interaction be- 
haviour of components, (2) a simple high-level notation for adaptor spec- 
ification, to express the intended connection between component inter- 
faces, and (3) a formal definition of adaptor, a component-in-the-middle 
capable of making two components interoperate successfully according 
to a given specification. 



1 Introduction 

Component adaptation is widely recognised to be one of the crucial problems 
in Component-Based Software Engineering [4,5,10]. The capability of adapting 
off-the-shelf software components to work properly within larger applications is 
a must for the development of a true component marketplace, and for component 
deployment in general [3] . The need for component adaptation is also motivated 
by the ever-increasing attention devoted to developing extensively interacting 
distributed systems, consisting of large numbers of heterogeneous components. 

Available component-oriented platforms address software interoperability at 
the signature level by means of Interface Description Languages (IDLs), a sort 
of lingua franca for specifying the functionality offered by heterogeneous compo- 
nents. While IDLs allow to overcome signature mismatches, there is no guarantee 
that the components will interoperate correctly, as mismatches may occur be- 
cause of differences in the interaction behaviour of the components involved [11]. 

The objective of this paper is to set a formal foundation for the adaptation of 
heterogeneous components that may present mismatching interaction behaviour. 
The notion of adaptor was originally introduced in [13] to name a component-in- 
the-middle aimed at enabling the successful interoperation of two components 
presenting mismatching behaviour. 
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4309-C02-02 and TIC2001-2705-C03-02 funded by the Spanish Ministry of Science 
and Technology (MCYT). 
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In our previous work [2] , we have developed a formal methodology for com- 
ponent adaptation that supports the successful interoperation of heterogeneous 
components presenting mismatching interaction behaviour. As pointed out in 
[13], the first step needed to overcome behavioural mismatch is to let behaviour 
information be explicitly represented in component interfaces. Process alge- 
bras feature a very expressive description of interaction protocols, and enable 
sophisticated analyses of concurrent systems. For these reasons, their use for the 
specification of component interfaces and for the analysis of component compa- 
tibility has been widely advocated (e.g. [1,7,9]). On the other hand, a serious 
drawback of employing process algebras is the inherent complexity of verification 
procedures, which inhibits their usability in practice. 

Therefore, a suitable trade-off between expressiveness and effectiveness of 
verification is needed to reason about component protocols. To this end, we pro- 
pose the notion of session for the description of component interfaces. Intuitively 
speaking, sessions feature a modular projection of component behaviour both in 
space and in time. On the one hand, each session describes a partial view of 
the behaviour of a component (w.r.t. another component that will be attached 
to it), thus partitioning the component behaviour into several facets or roles. 
On the other hand, each session describes a (possibly finite) connection, thus 
partitioning the full life of a component into a sequence of sessions. 

From a technical viewpoint, we will use session types (firstly defined in [6]) to 
describe component sessions as true types. The ultimate objective of employing 
session types is to provide a basic means to describe complex interaction be- 
haviour with clarity and discipline at a high-level of abstraction, together with 
a formal basis for analysis and verification. Session types are supported by a 
rigorous type discipline, thus featuring a powerful type checking mechanisms of 
component behaviour. Moreover, the use of types - instead of processes - to des- 
cribe behaviour features the possibility of describing recursive behaviour while 
maintaining the analysis tractable. 

The second ingredient necessary to address formally the issue of component 
adaptation is a suitable formalism to express adaptor specifications. Indeed, 
as shown in [2] , separating adaptor specification and adaptor derivation permits 
the automation of the error-prone, time-consuming task of manually construct- 
ing a detailed implementation of a correct adaptor. The desired adaptation will 
be expressed by simply defining a set of (possibly non-deterministic) correspon- 
dences between the actions provided by the two components to be adapted. As 
we will see, the distinguishing aspect of the notation used is that it produces a 
high-level, partial specification of the adaptor. 

In a third step, we define formally the notion of adaptor in terms of an adap- 
tor specification and of the session types of the components involved. Finally, we 
prove that adaptors guarantee the safe interaction of the components adapted, 
in the sense that they will never deadlock during an interaction session. 

The rest of the paper is organized as follows. Sect. 2 is devoted to introduce 
session types for typing component behaviour. After defining a process calculus 
to denote component protocols, a type system is introduced and the notion of 



44 



Antonio Brogi, Carlos Canal, and Ernesto Pimentel 



type compatibility is presented. In Sect. 3 adaptor specifications and the formal 
definition of adaptor are introduced, and the session-safety result is established. 
Finally some concluding remarks are drawn in Sect. 4. 

2 Typing Component Behaviour 

Process algebras have been widely used to specify software systems. In parti- 
cular, they have been often employed to describe the interactive behaviour of 
software components [1, 7, 9]. The advantage of having these formal specifications 
of components is two- fold. First, component behaviour is unambiguously fixed 
and it can be animated with a convenient interpreter tool. Second, it is possible 
to analyze a number of liveness and security properties such as safe composi- 
tion or replaceability in complex systems. In spite of the usefulness of process 
algebras for component description, they present an important drawback due to 
the complexity of the decision procedures to verify the mentioned properties. In 
order to cut off this complexity, we have applied to our context the notion of 
session type introduced in [6]. 

Session types present some important features that distinguish them from 
processes written in a general process algebra like the 7r-calculus: 

— session types abstract from data values, referring to the corresponding data 
types instead; 

— sessions are limited to diadic communications between two components; 

— mobility is expressed by means of explicit throw / catch actions, and since 
sessions are diadic, once a process throws a session, it cannot use it anymore; 

— no mixed alternatives are allowed: input and output actions cannot be com- 
bined in a non-deterministic choice. 

It is worth noting that these restrictions are not relevant limitations in our 
context, as we will show. On the contrary, they make session types a calculus 
much more tractable than other studied alternatives, like the 7r-calculus or CSP. 
A thorough discussion of the advantages of employing session types instead of 
other concurrency formalisms is reported in [12]. Under this approach, a process 
is viewed as a collection of sessions, each one being a chain of diadic interactions. 
Each session is designated by a private session name, through which interactions 
belonging to that session are performed. The use of diadic sessions for the speci- 
fication of software interaction allows a modular description of complex systems. 
The objective is to provide a basic means to specify complex interaction be- 
haviour with clarity and discipline at a high-level of abstraction, together with 
a formal basis for analysis and verification. 

Throughout the paper, we will use both a session type description language 
and a process calculus C. The former will be used to type the behaviour of 
components (and will be exposed in component interfaces), while the latter will 
be used to refer to (and exemplify) the actual implementation of components. 

2.1 A Process Calculus for Component Description 

In this section we present the process calculus for describing component imple- 
mentations. It is a variant of that used in [6]. Apart from some simplifications in 
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the notation, the main difference is that we allow the alternative composition of 
output actions (somehow equivalent to an if-then-else construct), and not only 
of input actions as in [6]. We give also a transition system for the calculus, not 
present in [6]. The syntax of the process calculus £ is defined as follows: 

P ::= 0 | act.P | klnii.Pi \ ^^klrrii.Pi \ P\ \\ P2 \ A{xk) 

i i 

act ::= x\request(k) j xlaccept(k) j k\throw{k') \ klcatch(k') 

where 0 represents the empty process, P, Pi denote a process, A is a process 
identifier, x denotes a link name, k and k' denote session names, 7 denotes a 
sequence of names, and nm denotes a message, syntactically composed by a 
message selector and a sequence of data arguments. 

For any process identifier A(xk) there must be a unique defining equation 
A{xk) = P. Then, A(yh) behaves like P{y/x,h/k}. Defining equations provide 
recursion, since P may contain any process identifier, even A itself. 

We consider two kinds of actions in the process calculus £ : output actions 
( k\rrii ), where a message m, is sent through a session k, and input actions [klrrii ), 
where a message mt is received through a session k. There are four special mes- 
sage selectors: request, accept, throw, and catch. All of them require a single 
argument representing a session name. A request output action issued on a link 
name x waits for the acceptance ( accept ) of a session on this link. When these 
two actions synchronize, a new session is created linking the processes where 
the interaction was performed. Similarly, throw and catch are complementary 
actions, too. In this case, an existing session (name) can be moved from a pro- 
cess (where the throw action is made) to another one (where a catch action 
is performed to capture the session). These last two actions permit to change 
dynamically the topology of the system. Notice that link names are only used 
to create sessions (via request/ accept actions), while all other interactions take 
place on session names. 

The transition relation described in Fig. 1 defines the operational semantics 
of £. There are both labelled and unlabelled transitions, the latter corresponding 
to silent actions. The four initial rules describe the behaviour of actions concern- 
ing session manipulations. Rules (req) and (acc) model session creation, while 
(thr) and (cth) model session transmission. Both accept and catch are bind- 
ing actions, receiving a new session name not occurring in fn(P) (free names 
of P). Rule (sum) defines the behaviour of a sum of (either input or output) 
actions A; = /c?m, or A i = khrii, respectively, which is modelled by the usual 
non-deterministic choice, assuming that the choice is made locally for output 
actions, and globally for input actions. To model the parallel composition of 
processes we have four different transition rules. Rules (PAR open ) and (PAR^ro™) 
model session opening and session throwing, respectively, whereas (sync) models 
the synchronous exchange of input and output messages. Rule (par) describes 
the standard interleaving of parallel compositions. Finally, rule (def) models 
process definition. Note that the label A in these last two rules may be empty. 
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REQ : 



. . . , _ xlrqttk) THR . . k\thw(k ) _ 

x\ request (k).P — > P k\throw(k ).P — + P 



ACC : 



x? accept (k).P x — P{/i/fc} 






CTH : 



klcatch{k').P k? ±i h) p{h/k'} 



-(hgfn(P)\{k'}) 



SUM : 



Ui=l 



(j = 1 ■ • • n) 



PARopen • 



p x\rqt(k) p, x? acp( k ) 

P II Q — ► P' || Q' 



PARi/j.T’oty : 
k\m 



P k\thw(k ) 



Q fc? ^ fc) Q' 



P || Q — > P' || Q' 



SYNC : 



P' Q k -PX Q' 



P || Q P' || Q' 



PAR : 



P' 



P || Q 



P' || Q 



P{y/x, h/k} P' . .. 
def : — lf// . ' \ (A(xk) = P) 



A{yh) 



P' 



Fig. 1 . Transition system for C. 



Additionally to the transition system in Fig. 1, we assume also standard commu- 
tativity and associativity axioms for choice and parallel composition operators. 

Throughout this paper we will use a simplified FTP system to illustrate 
the different aspects of our proposal. Suppose that the system is composed of 
a server, with whom clients interact for opening FTP sessions, and a set of n 
daemons, each one responsible for handling one client session: 

n 

S ystem(client, daemon) = Server (client , daemon) || ~^^Daemon(daemon) 

i — 1 

Suppose also that the specification in C of the Server component is: 

Server (client , daemon) = 
client?accept (a) . a?user(usr) . a?pass(pwd). 

( a!rejected("User unauthorized"). Server (client .daemon) 

+ a!rejected("Service unavailable"). Server (client , daemon) 

+ a! connected ! () . daemon ! request (b) . a!throw(b). Server (client , daemon) ) 

The FTP Server component declares two link names (client and daemon). The 
first one is used for its interaction with its clients, while the second is used for 
interacting with the daemons. When a request is received on link client, a new 
session a is created, for handling the interaction between the system and this 
specific client. Then, the client identifies itself, providing its name and password. 
As a result, the server may either reject (message rejected), or accept (message 
connected) the connection. In the latter case, the server requests on link daemon 
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a session b from one of its daemons, and throws the newly created session b to 
the client. Session a ends now, and the server returns to its original state, ready 
for attending a new client request. 

On the other hand, the daemon component can be represented as follows: 

Daemon(server) = server?accept (b) . Daemon2 (server ,b) 

Daemon2 (server ,b) = ( b?get (filename) . 

( b ! result (data) . Daemon2 (server ,b) 

+ b!nosuchfile() . Daemon2 (server ,b) ) 

+ b?quit(). Daemon(server) ) 

The specification above shows how once a new session b is established with 
the server, the daemon waits for different user commands (here, only get is 
considered, the rest being alike), finishing with a quit command, after which 
the session ends, and the daemon is ready for accepting a new session request. 
After each get command, either the corresponding data (result) or an error 
(nosuchf ile) is returned. Notice how the daemon remains unaware of the fact 
that the session b initially requested by the server is afterwards sent to the client, 
which is the one who actually performs get and quit commands. 

However, our interest is not focused on using a process calculus like C for 
describing the behaviour of software components, but rather in typing this be- 
haviour for establishing the correct interaction among the corresponding com- 
ponents. This is the objective of the next section. 



2.2 Typing System 

Whereas the type system defined in [6] deals both with data and session types, 
without loss of generality we shall omit data arguments in process definitions and 
message arguments. This simplification is not relevant, and our typing system 
could be easily extended to deal also with data. We will denote by TExp the set 
of type expressions constructed by following grammar: 

ol ::= 0 | T | \a \la | !(a)./3 | 1(a). (3 \l'^t i .a i \ A 

i i 

where a, at, (3 are type expressions, and A is a type identifier (we assume that 
for each identifier A exists a unique defining equation A = a). The constant 
type 0 represents inaction’s type, and _L denotes a specific type indicating that 
no further connection is possible at a given session. In other words, if a session k 
has a type _L in a process, then k is not offered by this process as an open session. 
Type expressions !a and ?a correspond to request and accept primitives, respec- 
tively, whereas !(a) and ?(cn) correspond to throw and catch. The expression t, 
denotes the type associated to a message (which will coincide with the message 
selector, since we abstract from message arguments). Then, the type ? 
denotes the branching behaviour given by a process which is waiting with several 
options, and which behaves as type on if the i-th action is selected. Similarly, 
! ti-OLi denotes the complementary selecting behaviour, w.r.t. output actions. 
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Given a type a where _L does not occur, we define its dual type a, as follows: 

la = la 1(a). p = 1(a). P ! 0 = 0 

la = la 1(a). p = 1(a). P l^U-Oi = l^U-ai 

The dual of a given type denotes the complementary behaviour of the original 
type, and a = a. It is obvious that the composition of a type and its dual is 
successful, in the sense that the corresponding processes will execute without 
deadlocks [6], eventually terminating in empty processes. However, imposing 
such a condition seems too restrictive in the context of real software components. 

In [12] a notion of type compatibility is defined in terms of a subtyping 
relation and type duality. Intuitively speaking, a session type cr is a subtype of 
P if a can be used in any context where P is used, and no error occurs in the 
session. Basically, this means that a should have more - or equal - branchings 
(input alternatives), and less - or equal - selections (output alternatives). Based 
on this subtyping relation, a is said compatible with /?, denoted by a txi p, if 
a is a subtype of the dual of p. Defined this way, compatibility is a sufficient 
condition to ensure successful composition of the corresponding processes. (More 
details about these subtyping and compatibility relationships can be found in 
[ 12 ]-) 

The typing system for the calculus C is shown in Fig. 2, and deals with 
sequents of the form: 0; T b P > A, which means: “under the current environ- 
ment, given by 0 and T, the process P has a typing A”. As in [6], 0 denotes 
a basis , which is a mapping from process names to the types in TExp of the 
corresponding arguments (links and sessions); while the sorting (t G)T stores 
types for links, which are expressed by means of sorts (a, a). A sort of this form 
represents a pair of complementary interactions which are associated with a link 
name: one starting with accept , and the other one starting with request. Each of 
them correspond to the type of certain session in the typing A, which is a partial 
mapping from session names to types. Given a typing (or sorting or basis) E, 
we write E ■ k : a to denote the mapping H(J{fc : a} provided that k dom(E). 

Using session types for describing component behaviour makes it possible 
to determine when two components can interact safely. This analysis will be 
done in terms of the compatibility of the typings of the components. Indeed, the 
notion of compatibility in [12], previously mentioned, can be naturally extended 
to typings. When two typings, A\ and A 2 , are compatible (A\ ex A 2 ), their 
composition (A\ 0 A 2 ) is defined as a new typing given by: 

{ T if k £ dom(Ai) n dom(A 2 ) 

A\(k) if k € dom(A{) \ dom(A 2 ) 

A 2 (k) if k € dom(A 2 ) \ dom(A \ ) 

As we have already said, the typing system in Fig. 2 is similar to that provided 
in [6], but adapted to the process calculus C. The first two rules define the sort 
associated to a link x , on which an accept or request is made. Notice that the sort 
for a; is a pair composed by the session type a and its dual, a being the derived 
type for the session opened on x. Rule 7 cth types a catch action, assigning to 



Behavioural Types and Component Adaptation 



49 



T. 



O: T P t> A ■ k : a 






ACC ' <9; P, x : {a, a) b x? accept (k) .P > A ■ k \?a 
6 ; T P t> A ■ k : a 



RE< ^ ' <9; T, x : (a, a) b x\ request (k).P t> A ■ k :\a 
<9; T b P > A ■ k : j3 



Tthr : 



e ; fb k\throw(k').P > A ■ k :\(a)./3 ■ k' : a 
O , r h P > A ■ k : f3 ■ k 1 : a 



T, 



IN 



Tout : 



Tr 



Tcth : H: r fe? catch A • b bio)..; 

0; r b Pi [> d • fc : tti • • • 0;Tb P n o A ■ k : a n 
0; r b X)™ =1 klrm.Pi > A-k\l J27= i 
(9; P b Pi > A ■ fc : ai • ■ ■ 6>; T b P„ > A ■ k : a„ 
0;Pb X)™ =1 k\rrii.Pi t >A-k:\ Yn=i mi -an 
0;P\~Pt>A 0- T \- Q t> A' 



PAR 



0; r b P II Q > A © A' 

^INACT : 



(A xi A') 



T n 



0;PbO>A 
0 ■ A : id; T ■ x : t \- P t> A ■ k \ a 
F O \ A; P, y : t b A{yh) > A ■ h : a 

Tvar : 



(A(xk) = P) 



0 • A : Da; P,y : t b A(yh) t> A ■ h : a 



Fig. 2. Typing system for the calculus £. 



the captured session fc' a type a, which is provided by the rule 7thr in the 
corresponding throw action. Rules 7 in and Tout define the expected type for 
a sum of input and output actions, respectively, where with abuse of notation, 
we still use m* to denote the type of the message mj. Rule Tpar defines the 
synchronization among processes having compatible types; the resulting type is 
given by their composition. Finally, the rules Tdef an d Tvar define the types 
for process definitions, where the information accumulated on the basis 0 about 
process variables may be used to type recursive definitions. We assume that the 
range of A in Tjnact and Tvar contains only 0 and _L. 

If a type sequent 0; P b A(xk) > A is derivable from the typing system, we 
say that the process A is typable , and its type, denoted by [A], is determined by 
the types associated to each link a; of A in P, and to each session A: of A in A. 
We write [A] x to denote the session type for x in the process A. Given a link 
a; of a typable component A, we will denote by k x the session that A opens on 
link x. Then, we have that [A] x is the session type a (respectively, a) such that 
x : (a, a) is in P, and the session k x has type a (respectively, a) in A. Thus, 
from the point of view of A, the type of a link x is the type of the session k x 
opened on that link. Hence, we usually write [A] a, and [A}k x interchangeably. 

Let us show now which are the types corresponding to the FTP system of 
our example. Starting from the daemon component, its type [ Daemon ] is given 
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by the type DAEM0N_b, assigned accordingly to the typing system in Fig. 2 to 
the session b that a daemon establishes with the server: 

DAEM0N_b = ? DAEM0N2_b 

DAEM0N2_b = ?(get. ! (result .DAEM0N_b + nosuchf ile . DAEM0N_b) + quit.O) 

On the other hand, the type of the server component [Server] defines two session 
types: SERVER_a for the session a it establishes with the client, and SERVER_b 
for the session b it establishes with the daemons: 

SERVER_a = ? ?user. ?pass. 

! ( rejected. 0 + connected. ! (SERVER_b) . 0 ) 

and, from rule 7 thr> we have that SERVER_b is precisely the type dual of 
DAEM0N_b (and notice that by definition of 0 their composition is _L). Con- 
sequently, the type for the whole FTP system, obtained composing the typings 
of the server and the daemons, is: 

[System] = { a : [ Server] a , b : [ Server]b 0 [ Daemon\b } = { a : SERVER_a, b : _L }. 

We can see several interesting differences between the specification in C of the 
components previously shown and their corresponding session types above. First 
of all, session types describe the behaviour of the component during a single 
session (that is, from the point where a new session name is created in an 
accept / request , to the moment where this session is no more used, and its name is 
lost). Hence, session types describe usually a finite pattern of actions (as it can be 
seen in particular in the session types of the server component). Second, session 
types separate the interleaving of actions performed on different session names, 
allowing a modular description of interactions. On the contrary, the process al- 
gebra specification describes the full behaviour of the components, interleaving 
actions from different sessions (as in the case of the server component), and is 
usually recursive to an accept or request action. 

Now, we could write the session type of an FTP client component perfectly 
compliant (that is, dual) with the server and the daemon described so far, en- 
suring successful interaction among them. However, our objective is to deal with 
component adaptation, and for this reason, a more interesting (although very 
simple) client is represented below (on the left the component, on the right the 
corresponding type): 

Client (server) = server ! request (c) . CLIENT_c = ! 

c ! login(usr ,pwd) . (login, 

c ! download (filename) . (download. 

c?data(f iledata) . 0 ?data. 0 

It is easy to see that the above client is not compatible with our FTP system 
(and obviously the corresponding components would deadlock when composed 
in parallel). Indeed, the more relevant differences between them are: 

— The name of the messages used in both types are different, though we could 
guess some correspondences between them (e.g., get and download). 
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— Also the protocols of the components are different. For instance, the DAEM0N_b 
type recurs until a quit message is received, while the client just performs 
a single download command. 

— The client ignores the throwing of a daemon session from the server. Instead, 
its behaviour is represented by a single session. 

— Finally, the client unwisely ignores any error message coming from the server. 



3 Adaptor Specification 

In this section, we introduce a simple, high-level notation for describing the in- 
tended correspondence among the functionality of two components being 
adapted. This correspondence is specified by means of a mapping that estab- 
lishes a number of rules relating messages of both components. This specification 
will be then used for the automatic construction of an adaptor that mediates 
the interaction of the two components. 

A detailed description of the notation for adaptor specification can be found 
in [2], Here, we will show only how we can use it for accommodating the differ- 
ences between the types SERVER_a and CLIENT_c above. The intended adapta- 
tion between them may be represented by the following specification: 



{ ! login (usr , pwd) 


<> ?user(usr), ?pass(pwd); 


// rl 




<> Irejected(msg) ; 


// r2 




<> ! connectedO ; 


// r3 


! download (f ilename) 


<> ?get (filename) ; 


// r4 


! download (f ilename) 


<> : 


// r5 


?data(f iledata) 


<> ! result (f iledata) ; 


// r6 


?data("No such file") 


<> Inosuchf ile () ; 


// r7 


?data("Not connected") 


<> ; 


// r8 




<> ?quit () ; > 


// r9 



where the actions of the client are represented in the left terms while those of 
the server (and its daemons) are on the right. 

The specification S establishes a correspondence between messages in both 
components. For instance, the login output message in the client is mapped 
to a pair of user and pass actions in the server, as indicated in the first rule. 
Instead, server’s messages rejected, connected or quit have no correspondence 
in the other part (rules r2, r3, and r9). Finally, some other messages, like client’s 
data may correspond to different actions in the server, like result (rule r6), 
nosuchfile (rule r7), or even to no action at all (rule r8). 

An adaptor specification defines the properties that the behaviour of an adap- 
tor component must satisfy [2], Each rule in a specification can be translated 
into a term in the process calculus C. For instance, for the rule rl, we have:S 
Rl(l,r) = l?login(usr ,pwd) . ( r luser(usr) .0 I I r?pass(pwd) .0 I I Rl(l,r) ) 
meaning that if the adaptor accepts a message login from the component at 
its left (represented by the session 1), then it will eventually perform one action 
user and one action pass in its interaction with the component at its right. 
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Given an adaptor specification, we say that a process A satisfies it, if A 
fulfills the rules of the specification. Formally, this means that the process A is 
simulated by the parallel composition of the rules of the specification [2] . 

The specification S above provides a minimal description of an adaptor that 
plays the role of “component-in-the-middle” between the FTP system and its 
client, mediating their interaction. The ultimate goal of such a specification is to 
obtain an adaptor, a component both satisfying the specification, and providing 
the required adaptation between the components being adapted. 

Formally, the notion of adaptor is introduced as follows. 

Definition 1 (Adaptor). Let ap and (3 q be sessions types for two components 
P and Q, respectively, and let S be an adaptor specification. A process A(l,r ) is 
an adaptor for a p and oq under S iff: 

1. A(l , r) satisfies S, and 

2. [A] i [xi ap and [A] r cxi olq . 

The adaptor A is a process with two session types, ([A]j and [A] r ) - one 
for each component to be adapted -, compatible with the corresponding ses- 
sion types ap and oq. The two conditions a process has to satisfy to be an 
adaptor ensure that: (i) the process follows the adaptation pattern given by the 
adaptor specification, and (ii) the parallel composition of the adaptor with the 
components P and Q is “safe”, as we will illustrate later. 

Given an adaptor specification, and the session types of the components to be 
adapted, an automatic procedure [2] deploys a concrete adaptor (not a type, but 
an actual component, here represented by a process in £), that both satisfies the 
specification, and adapts the mismatching behaviour of the actual components 
represented by those session types. For instance, for the previous specification 
S, and the session types of the FTP client and server (CLIENT_c and SERVER_a, 
respectively), a possible result of the generation procedure is the adaptor: 

Adaptor (l,r) = 

l?accept(x). r ! request (y) . x?login(usr,pwd) . yluser(usr) . ylpass(pwd) . 

( y?connected() . y?(z). x?download (filename) . z ! get (filename) . 

( z?result (f iledata) . x ! data(f iledata) . z!quit(). 0 
+ z?nosuchf ile() . x!data("No such file"). z!quit(). 0 ) 

+ y?rejected(msg) . x?download (filename) . x!data("Not connected"). 0 ) 

The adaptor above has two link names l and r for interacting with its left and 
right counterparts (the client and the server, respectively). In the first two ac- 
tions, a session is opened on each of these links, and then the adaptor begins 
to interact with the client and the server following the behaviour represented 
in their session types, and according to the correspondence between messages 
indicated in the specification S. Thus, the initial client’s message login is trans- 
mitted to the server by means of one user and one pass message (rule rl in S). 
If the server replies with a connected message (without correspondence in the 
client, as per rule r3), then a daemon session z will be accepted by the adaptor 
and the interaction goes on through this session (note how the client remains 
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completely unaware of this fact). The following client’s action download will be 
transmitted by a get (rule r4), and the reply of the daemon (either result or 
nosuchfile) will be returned to the client with a data message (rules r6 and 
r7). Anyway, in both branches the client closes its session at this point, and the 
adaptor also ends by sending the quit message (rule r9) the server is waiting 
for. On the contrary, if the server rejects the connection and closes the session, 
client’s message download will not be transmitted (rule r5). Instead, the client 
will be replied with a "Not connected" indication in a data message. 

3.1 Safe Composition 

As we already mentioned, the conditions to be fulfilled by an adaptor guarantee 
the safe interaction of the components to be adapted. In order to clarify what 
we mean by that, we introduce the notion of session-safety. 

Definition 2 (Session safety). A process P in C is session safe for a set of 
links L if for every trace P — E we have that either: 

1. E = 0, or 

2. if E — then f = xlacp(k ) or f = x\rqt(k ) for some link x £ L and some 
session k. 

Session safety states that a process does not deadlock in the middle of the com- 
putation of a session. In other words, once a session is open, then it will finish 
without deadlocks. We now prove that the definition of adaptor ensures the 
conditions for guaranteeing that the interactions are safe. 

Proposition 1. Let P, Q, A be three processes sharing only two sessions (ki, k r ), 
such that [P]ki lx [A]*,,, [Q\k r X [Afy r , and for every session k £ {ki : k r } we have 
[P]k = [A]fc = [Q\k = _L Assume that fn{P) (T fn(Q) — 0 (i.e. P and Q do not 
interact each other). Then , for E = P || A || Q we have that either: 

1. E = 0, or 

2. if E-f->, and P — or Q — , then for some link x, 
f £ {x\rqt{ki),x! acp(ki),x\rqt(k r ),xl acp{k r )} , or 

3. E — * P' || A' || Q' where: 

(a) P' = P, [A'] kl = [A] kl , [A'] kr x [Q']k r , or 

(b) Q’ = Q, [A 1 ]^ = [A] fcr , [A'] kl cxi [P']k t 

Proof. Let us suppose E ^ 0, E-f -> , and P (analogously if Q — ). 

If, for any link x, £ ^ {x\rqt(ki), xl acp{ki)} 1 then £ is one of the following 
transition labels: ki\thw(k), k{!cth(k ), fy!m, or fcfym (for some session k and 
message m). In any of these cases, as [P] kl x [A] kl , the process A would present 
the corresponding complementary action, and therefore P || A — » , which 
contradicts the original hypothesis ( E-f-A ). If E — > P' || A' || Q' , then (as 
P and Q does not share names) the interaction comes from a synchronization 
made by A and either P or Q. Let us assume the interaction is produced by the 
parallel composition of A and P. Then, clearly Q' = Q. Moreover, since the only 
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session shared by A and P is ki, we will get [A')k r = [A\k r - Finally, it is easy to 
prove (by structural induction on the transition system of C) that [A'] kl cxi [P']k, ■ 
Analogously, if the interaction is performed between A and Q. □ 

Proposition 1 establishes a correspondence between a property on session types 
(compatibility) and the way the corresponding processes proceed. The theorem 
below generalizes this result, and proves that a deadlock- freedom result for the 
parallel composition of two processes can be deduced from the compatibility of 
the corresponding session types. Of course, this result is only derivable when 
processes do not interact (among them or with others) through other sessions. 

Theorem 1. Let P, Q, A be three processes sharing only two links { l,r } such 
that fn(P)nfn(Q) = 0, and for every session k ^ {ki,k r } we have [P]fc = [A\ k = 
[Q]k = JL, If A is an adaptor for [P]i and [Q] r under a certain specification S, 
then P || A || Q is session safe for {l,r}. 

Proof. We will prove the following equivalent result. One of the following situa- 
tions hold, for every trace P || A || Q — E: 

i. E = 0, or 

ii. if E-f-> and E — , then £ S {l\rqt(ki), l?acp(ki), r\rqt{k r ), r?acp(k r )}, or 

iii. E = P’ || A! || Q’ where [A' ] fcl ix [P’] kl and [A'] kr cxi [Q'] kr . 

Now, we reason by induction on the trace length. The base case is trivial, because 
E = P || A || Q, and then we can apply previous Proposition. Let us assume 
the statement if true for every trace with length n (inductive hypothesis). Then, 
if we consider a (n + l)-trace P || A || Q — > n E' — > E, by applying the 
inductive hypothesis to the first n transitions, we obtain E' = P' || A! || Q’ 
where [ A']i ex [P']i and [A'] r cxi [Q'] r (note that two first statements of the 
inductive hypothesis are not applicable because E' — » E ). Therefore, by 
Proposition 1, E = P" || A" || Q" satisfying either (3. a) or (3.6). In both cases, 
P" , A" and Q" satisfy the desired requirements. □ 

Notice that the conditions of the theorem ensure that the components being 
adapted will not deadlock in their interaction with other possible components of 
the system, and this is the sense of enforcing that the type of every session on 
links different from l or r is _L. If this were not the case, obviously we could not 
ensure session-safety since a deadlock occurred in another session would deadlock 
the whole component, including sessions ki and k r . 

Returning to our example, the types corresponding to the Adaptor (l,r) 
component above are: 

ADAPT0R_1 = ? ?login. ?download. Idata. 0 

ADAPT0R_r = ! !user. Ipass. (?connected. ?(ADAPTQR_z) . 0 + ?rejected. 0) 
ADAPT0R_z = !get. ( ?result . !quit. 0 + ?nosuchf ile . ! quit . 0 ) 

and it can be easily proved both that the adaptor satisfies the specification S 
and also that its types are compatible with those of the client and the server: 
CLIENT_c cxi ADAPT0R_1 and ADAPT0R_r x SERVER_a. Hence, we are under 
the conditions of Theorem 1, and we can conclude that the system: 
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Client(l) || Adaptor(l,r) || Server(r,s) || J ~^Daemon(s) 

i= 1 

is session-safe for the links {Z, r}, and now these components are able to interact 
successfully. Indeed, after the client performs its FTP session, both the client 
and the adaptor end, and the FTP server and its daemons are again in their 
original states, all of them expecting to perform an accept action, requested by 
a new client (that may need a completely different adaptation). 

4 Concluding Remarks 

The objective of this paper was to set a formal foundation for the adaptation of 
heterogeneous components that may present mismatching interaction behaviour. 
The three main ingredients of the methodology of software adaptation that we 
began to develop in [2] can be synthetised as follows: 

— IDL component interfaces are extended with an explicit description of the 
interaction behaviour of a component; 

— the desired adaptation is specified via a simple set of (possibly nondetermin- 
istic and partial) correspondences between actions of two components; 

— a concrete adaptor is automatically generated (if possible), given its partial 
specification and the interfaces of two components. 

In this paper we improved the methodology with the adoption of session types to 
describe the interaction behaviour of components. As shown in Sect. 2, session 
types feature a disciplined, modular representation of behaviour at a suitable 
level of abstraction. Most importantly, their type discipline permits a rigorous 
type checking of component protocols that paves the way for rigorous analysis. 

The adoption of session types also permits to describe recursive component 
protocols, which could not be fully achieved in [2] where component interfaces 
could only declare finite, non-recursive interaction patterns followed by a com- 
ponent. It is important to stress that while session types permit to describe 
recursive protocols, their analysis and verification remains tractable. 

One of the main contributions of this paper is the formal definition of the 
notion of adaptor, and the proof that any adaptor for (the session types of) two 
components guarantees their correct session- wise interaction (Sect. 3). 

Session types were originally introduced in [6] . Our treatment of session types 
however differs from [6] in that we employ a more expressive process algebra 
(and formally define its operational semantics), while simplifying the sometimes 
cumbersome notation used for session types in [6]. Moreover, our notion of type 
compatibility relies on the notion of subtyping introduced in [12], rather than 
coinciding with the more restrictive notion of type duality used in [6] . 

One of the advantages of using session types is that they can cope with 
heterogeneous descriptions of component interfaces. Namely, if the protocols 
of different components have been expressed using different formalisms, such 
protocols can be typed into the corresponding session types, providing so an 
homogeneous way of dealing with the composition of third-part components. 
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Indeed, we argue that the introduction of behavioural types in component 
interfaces is necessary to achieve a systematic component-based software devel- 
opment, capable of guaranteeing properties of the resulting systems. The results 
presented in this paper are a step in this direction. Our plans for future work 
include the integration of the proposed adaptation methodology with available 
CBSE environments so as to promote its experimentation and assessment. 

Space limitations do not allow a proper comparison of our adaptation method- 
ology with other proposals, including those centering on the introduction of con- 
nectors in software architectures (e.g., [8]). A thorough comparison of our adap- 
tation methodology with other proposals can be found in [2], while a detailed 
comparison between session types and other formalisms is reported in [6] . 
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Abstract. In this work we study the unification of heterogeneous par- 
tial specifications using category theory. We propose an alternative to in- 
stitution morphisms, which we call (abstract) correspondences carrying 
specifications. Our methodology is illustrated using a categorical speci- 
fication style inspired by the state-and-operations style of Z as well as a 
categorical unification procedure. 

Keywords: partial specification, viewpoints, UML, Z, LOTOS, category 
theory. 



1 Introduction 

The development of large software projects raises specific problems and rich pal- 
lets of techniques and methodologies have been proposed in response. Here, we 
consider the method of partial specification or viewpoints. A partial specifica- 
tion focuses on a particular aspect or subsystem, with the intention that it is 
still small enough to be embraced, while still containing complete information 
about its particular concern or perspective. A system is then described as a 
collection of partial specifications, each from a different perspective or “view- 
point”. Important issues arising from such approaches are consistency of the 
different descriptions, and how specifications or systems can be constructed that 
simultaneously satisfy all of them (“ unification ”). 

Prominent examples of partial specifications system development models 
include the Reference Model for Open Distributed Processing (RM-ODP) [3], 
Viewpoints Oriented Software Engineering (VOSE) [16] and object-oriented 
analysis and design models such as UML [25] . Partial specifications are also the 
cornerstone of the newly approved standard IEEE 1471 [19]. This standard pre- 
scribes the description of software architectures by multiple partial specifications 
(called views), each one being an instance of a previously defined viewpoint. 

A similar style of specification occurs naturally in telecommunication sys- 
tems, which are often described as collections of features. Feature interactions 
are a real problem for telecom companies - they may be viewed as a consistency 
issue between partial specifications. 

This paper builds upon the partial specification approach for formal meth- 
ods developed by Bowman, Derrick, Boiten, et al [3, 4, 6, 13]. We investigate 
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the categorical foundation of this approach and develop a topos theoretic for- 
malization, based on the principles set out in [2, 6, 7]. Here, we concentrate on 
specific ingredients of the partial specification method, in particular on the role 
of correspondences. We define the notion of a specification style, and provide a 
topos theoretic formalization of Z to support the state-and-operations style, em- 
phasizing a constructive categorical technique for unifying partial specifications. 

The paper is structured as follows. In the next section we give an overview 
of partial specification, its main challenges and the most important approaches. 
We identify the need for a unified and uniform formalization, and suggest cate- 
gory theory as a potential mathematical framework. In Section three we present 
a small but intricate example through three partial specifications in a variety 
of formalisms, all describing simple labelled transition systems. We show that 
the standard categorical semantics of each partial specification’s language helps 
very little in relating these partial specifications. In Section four we propose a 
solution, inspired by this example. We propose that every partial specification 
should be accompanied by an alternative, possibly simpler, semantics called ab- 
stract correspondence. A specification style is then a formally defined abstract 
correspondence. The next section presents a categorical account of partial specifi- 
cation unification in the state-and-operations style of Z. The Conclusions section 
ends the paper. 

The categorical framework we propose for correspondence carrying specification 
is largely inspired by Z, but generalises its classical set theoretic basis to a topos 
theoretic basis. This allows non-classical logic variants of Z to be derived, as 
well as constructive versions and alternative notions of subtyping (the standard 
Z type system is a particular instance, called maximal types). 

We assume the reader is familiar with specification notations such as Z [12], 
algebraic specification [17], LOTOS and its structured operational semantics 
[13]. We make use of formal category theory [20], FCT for short, introduced by 
S. Mac Lane in 1969 as the branch of mathematics that studies the foundations 
of category theory using category theory itself [20]. We use double categories for 
modelling structured operational semantics, and the formalization of the state- 
and-operations style from [7] within the bicategory of relations [9] . In Section 5 we 
make use of internal category theory [5] . The unification construction is internal 
to the topos introduced in Section 4.3. 

2 A Quick Tour of Partial Specification 

Viewpoint methods have been studied extensively [16], particularly in the con- 
text of requirements engineering. Here, we describe a particular variant, using 
formal methods, which one might call the ‘Development Approach’, by the Kent 
group (Derrick, Bowman, Boiten, Steen, Linington [3, 4, 13, 12]). The consis- 
tency of partial specifications is initially defined as the existence of a common 
implementation. The term ‘ development relation ’ is used to collect concepts like 
refinement, implementation, and translation. A sufficient condition for showing 
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the existence of a common implementation is to find a common development. In 
order to reduce the global consistency check of multiple partial specifications of 
the same system to an iteration of binary consistency checks, additional condi- 
tions are required. 

The definition of consistency in this approach is [4] : “A set of partial system 
specifications are considered to be consistent if there exists a specification that is 
a development of each of the partial specifications with respect to the identified de- 
velopment relations and the correspondences between the partial specifications” . 
This common development is called an integration. A special case of this is the 
least developed integration. This is called unification and all other integrations 
are developments of it. 

The Development approach naturally generalizes to a categorical one. We 
aim to construct a practical categorical framework for studying the consistency 
and the unification of partial specification. 

Partial specifications can overlap in some common parts of the envisaged 
system that they describe. Redundancy between a set of partial specifications 
implies that one partial specification contains information about another one. 
Thus it is necessary to describe the relationship (“ correspondence ”) between 
the partial specifications. In the simplest case, two viewpoints refer to the same 
entity using the same name (and give it the same type), in which case the corre- 
spondence is implicitly characterised by equality of names. In complex applica- 
tions, explicit correspondences between the partial specifications are needed (e.g. 
correspondences between complex behaviors or types) . We need to represent cor- 
respondences in the categorical framework. The “interconnections” in algebraic 
specifications [15] serve to identify commonalities in the partial specifications, 
and to form the basis of the co-limit diagram that defines the composition. Cor- 
respondences appear to play a similar role, which would suggest that they could 
be modelled as objects (with particular outgoing arrows) as well. In our alge- 
braic approach, correspondences are expressed using relations, defined as a span 
diagram. 



3 Heterogenous Specification 

Previous work has concentrated on partial specifications written in the same 
language. If partial specifications represent different aspects, it is likely that 
each would use a different language appropriate to its particular concern. Indeed, 
major application areas like UML require a heterogeneous approach. 

Here, we present the main example for this paper. It consists of a heteroge- 
nous partial specification of a simple system, a ‘door’. On the basis of this, we 
discuss the algebraic semantics of the underlying specification languages. 

3.1 An Algebraic Specification View 

We use a general purpose algebraic specification notation, with a boolean (meta) 
type bool, based on partial conditional equational logic ( VCEC ). 
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Spec AS 
sort door 
opns init: door 

isopen : door — ► bool 
move : door — > door 
hello : door door 
var D : door 
eqns 

isopen (init) . 

isopen(move(D)) = not(isopen(D)). 
isopen(hcllo(D)) if isopen(D) 

end 

The standard (initial) algebraic semantics of AS is an algebra A , whose carrier 
| A | has two elements, True and False, obtained by partitioning the set of terms 
by the predicate isopen. A has a total operation move, equivalent to negation, 
and a partial one, hello, equivalent to the identity on the value True. 

The modern categorical semantics of algebraic specification is based on the 
concept of institutions [18]. An institution consists of 

— a category of signatures SIGN; 

— two functors Form and Mod from SIGN, associating to each signature E a 
set of formulae Form[E ] and a category of algebras Mod[E], and 

— a satisfaction relation between formulae and algebras, for each signature E, 
subject to an invariance axiom. 

An institution for VCSC is presented in detail in [17]. 



3.2 A Process Algebraic Partial Specification 

We describe a simple process in the process algebra LOTOS. 
P := open ; Q [] exit 
Q := hello ; Q [] close; P 



Categorical Operational Semantics. The ‘natural’ semantics of LOTOS is given 
in terms of structured operational semantics (SOS). The SOS rules have been 
formalized categorically as natural transformation [26] and structured coalge- 
bras [9] . Both axiomatizations are instances of formal category theory [20] . We 
propose here a formulation of SOS rules as double cells, derived by applying the 
tile calculus [9] to LOTOS. To a transition s A t of the Its ( A , T, — >C T x Ax T) 
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where a = a\ ® ... (g» a n is the product object in the Lawvere theory [9] THa 
associated with the process signature A. We use objects of THa to model the 
number of premises in a SOS rule. 

The SOS semantics for LOTOS is given by the following set of double cells 
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The SOS rules form an object in a double category SOS, by defining a morphism 
between the double cell sets U G| DC | and V G| DD | as a triple ( Fh,F v ,f ) 
where Fj , : DC/,-» DD/, and F v : DC„— > DD„ are functors and / : U — » V is 
a function preserving all kinds of identities and compositions. The function / is 
defined as f(u) : F h [x\ — *■ F h [y] G DD,, and F v [v] : F v [x] F v [y\ G DD„ for 
any u : x y G DC/, and v : x — > y G DC„. The composition of SOS rules is 
modelled by the left adjoint of the forgetful functor from DCAT to SOS. 

For example, the process term open ; close ; exit is derived as follows 





1 


open 


^ close 


1 




open 


T 


id 1 


T 


t id 1 






1 


— > 


l — » 


1 








id\ 


close 






close 


T 


close 


T 


t id 1 






l 


> 


l — » 


1 








idi 


idi 






exit 


T 


exit 


T 


t exit 






0 


» 


o — » 


0 








ido 


ido 


1 


open ; close ^ 


Composing all double cells one 


obtains open; close; 


exit | 


f exit 










0 


— > 0 












id 0 


that corresponds to the transition open; close; exit oper h_H ¥ ose 


exit. Observe that 



composing cells along the columns results in the set T of all possible terms, 
corresponding to the state of the Its semantics of the LOTOS process, whilst 
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composing double cells along the rows gives the set of all allowable sequences of 
actions, that corresponds to the trace semantics of the LOTOS process. 

Bisimulation can be defined as an equivalence on T following [9], and the 
resulting Its is drawn below 



open 




close 



3.3 An Object Oriented View 

The next partial specification uses a OCL style notation. We use “@pre” to refer 
to initial values in postconditions as proposed in [23] . 
let isopen: bool 
let oc,cc: integer 
method reset 

post: oc = 0 AND cc = 0 
method open 

pre: not(isopen) 
post: oc = oc@pre + 1 
method close 
pre: isopen 

post: cc = cc@pre + 1 

This partial specification uses a richer state, a counter for each transition 
being added. Moreover, the transition ‘hello’ is missing. 

A semantics for OCL, with some institutional flavor, has been proposed in 
[21]. In this work we make use of a translation of OCL into Z, as in [25]. 

4 Relating Partial Specifications 

In this section we relate the partial specifications given previously. The first 
way one might try to do this is to relate the specification languages, with some 
help from category theory. Despite initial optimism inspired by research in the 
field, many researchers in formal methods found the approach rather unpractical, 
especially because translations are defined only for a limited set of logics. In this 
section we argue for a different category theory based methodology to relate 
the partial specifications. This defines translations locally in a manner specific 
to the partial specifications involved. We call this methodology correspondence 
carrying specification and it is the main topic of this work. 

4.1 Language Translations 

The theory of categories appears a natural formalism for defining translations 
between different formalizations. However, in formal specification we are inter- 
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ested in practical solutions. In this section we investigate to what extent category 
theory provides useful translations for our example. 

Let us consider the first two partial specifications. The ‘natural’ way to trans- 
late one partial specification into another is to use a translation LT between their 
languages. LT should define a translations between semantics, i.e., use institution 
morphisms [17]. Such a translation can be constructed in three steps: 

1. define an institution for LOTOS; 

2. chose a suitable definition of morphism; 

3. ensure that the translation LT is related to the two dimensions of the process 
algebra semantics. 

The first aspect seems to be the most difficult. There is no institutional se- 
mantics for LOTOS reported in the literature, and the invariance axiom seems 
difficult to satisfy in LOTOS semantics. A solution would be to first translate 
LOTOS into a suitable formal notation with an institutional semantics, such as 
temporal logics [15]. This solution, acceptable from a categorical perspective, is 
against the spirit of partial specification: partial specification stakeholders must 
have their freedom respected in choosing their own expertise language. A trans- 
lation of a partial specification could not be transparent to its own stakeholder 
and this is the purpose of any support tool (software or theoretical). But this 
is not possible for our example: the institution VCSC offers too poor seman- 
tics, and this is because there is no distinction between operations constructing 
states and those denoting transitions. Therefore, the existence of any translation 
is conditioned by further information from the stakeholder. This (necessary) ad- 
ditional information is formalised in our approach as abstract correspondences 
in the next (sub) section. 

The second aspect, although it looks the easiest, is actually more difficult. Re- 
search on institutions has so far failed to agree on a definition of morphism. Soft- 
ware specifiers cannot realistically be expected to make the choice between the 
various alternatives proposed. The existing approaches to heterogeneous specifi- 
cation based on Grothendieck institutions [22] are not suitable for partial spec- 
ification: it is not possible to model the concept of correspondence and they are 
applicable only to those formal notations that admit institutional semantics. 

The answer to the third question is related to the particular property of 
institution morphisms, namely that they define both syntactic and semantic 
translations such that satisfiability is preserved. For process algebras, syntax is 
related to SOS rules and not directly to Its or trace semantics; the latter are 
derived. 

An advantage one might get by avoiding complete language translations can 
be found in the SOS semantics of the process algebraic partial specification. 
Indeed, SOS semantics is, in fact, a metalevel semantics: it does not describe a 
Its for a process, but a set of rules to construct that Its. This is why institution 
morphism theory is difficult to apply in our example. The metalevel of semantics 
is reflected categorically in the extra dimension of semantic category: we have 
to move to double categories. 
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The OCL partial specification provides another example of a domain where 
metalevel semantics is present: UML [2]. Metamodelling is frequently used in 
UML, where UML itself is used to give semantics of UML [14]. In the absence of 
a ground, solid formalization of metalevel semantics, metamodelling rather seems 
to express the lack of semantics. This is why FCT promises to offer a potential for 
transforming the metamodelling methodology of UML into a formal specification 
tool. 

The most important use of FCT can be obtained when considering the state 
and operations style of Z. Its categorical formalization is done using FCT, viz. 
the bicategory of relations RELr over a regular category [24] R. The metalevel 
interpretation is as follows: the states are viewed as objects of a regular category 
R. State transformation is done by operations, and their formalization is done 
by considering an extra dimension (i.e. a meta reasoning over states) to R, 
namely constructing the bicategory RELr. Considering refinement, modelled 
as relational inclusion, one gets a three-category. 

4.2 Abstract Correspondences 

An abstract correspondence (AC) is a semantic description of the partial speci- 
fication, which helps to derive concrete correspondences with respect to another 
partial specification. AC is a simplification of the standard semantics of the 
partial specification or may be written in a different language. 

The algebraic specification in our example is relatively difficult to relate 
with the other partial specifications because its standard semantics provides an 
algebra. In our example, an useful AC associated with the AS partial specification 
is the Its drawn below 

move 

False 



move 




Our alternative to institutions is to use a categorical semantics of the state- 
and-operations style derived from Z. The above Its semantics can be rigorously 
specified by considering states with no structure - a simple set of states 
ST ::= False \ True 

and operations defining in a compact manner possible transitions, like 



States 
s : ST 



Hello 

AStates 

s = True A s' = True 
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Move 

AStates 

(s = True A s' = False) V (s = False A s' = True) 



AC is specific to a partial specification, and not to a language. Two different 
partial specifications, written in the same specification language, can have very 
different ACs. However, we can have the situation where an AC can be extended 
to the whole language. We call such an AC a specification style. This is an 
alternative, simpler (for a specific use) semantics of the language. In our view, 
the main contribution of the theory of institution to formal logics consists in the 
introduction of localisation. The satisfaction relation is not defined for the entire 
language as in most formal logics, but locally, for every signature separately. 
The global aspects of logics are then recovered by introducing the invariance 
condition, and most mathematical results of the theory consist in re-establishing 
globality. We develop a constructive interpretation of this localisation principle 
as ACs. 

For us, the most relevant specification style is the state-and-operations style 
in Z. The standard semantics of Z offers no operational interpretation of op- 
erations: they are just sets. The usual interpretation is that an operation is a 
relation between the semantics of pre and post states. 

4.3 A Categorical State-and-Operations Style for Z 

This section establishes the home category of our categorical investigation fol- 
lowing a categorical type theory analysis of Z. 

The Z Type System. The primitive types in Z are numbers and the given sets 
G (i.e. sorts in algebraic specification terms). Types are constructed from the 
basic types using type constructors. The type constructors include power set and 
product. The formalization of types proposed here has Standard Z as a model, 
but also variants such as Constructive Z or multi-valued logic variants of Z. The 
logical constructors with possibly multiple interpretations are marked using the 
- decoration. 

Standard given sets comprise the singleton type i, the integers Z, the Booleans B, 
and any other given sets defined without further information on their structure. 
Type constructors are formally defined as: if a and (3 are types, so are P a (the 
power set), a x /3 (product) and [a^ : af\i^i (schema type; all labels ai must be 
different) . 

Terms are defined recursively as follows: 

— for every type a we consider countably many variables of type a. We write 
x : a for a variable x of type a 

— * is a term of type i (i.e. i = {*}) 

— true : B. Moreover, if a,b,cf>(x) : B (with (j) -possibly- containing the free 
variable x : a) so are a A b, a =4- 6, V x : a • <f>(x). 
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— 0 is term of type Z, and, if n : Z then so are Sn and — n 

— if a : a and b : (3 then < a, b >: a x (3 

-if Xi : at for all i G /, then (| _a» == x t Die/ : [a* : aj]ie/ 

— if a : a and u : P a then (a G u) : B 

— if <j){x) : B (possibly) contains the free variable x : a then {x : a | (j)(x)} : Pa 
Important particular terms can be defined as follows 

— false : B is defined as V a : B* a and (A a) : B is defined as a false 

— 3i:a« (j>{x) : B is defined as V c : B*(V x : a • (cj)(x) c) c) 

— (a = 6) : B is defined as V w : Pa*(a G w b G m) 

— {a} : Pa is defined as {ir : a \ x = a} where a : a 

States 

The Z Standard document defines the semantics of a state as a set of bindings 
(members of a schema type). 

The next result allows us to define semantics of a Z type as an object in a topos. 

Theorem 1. Every model of a Z's type system is equivalent with a relational 
category over a topos, that we denote by MOD. 

This result imposes a change in the categorical formalization of the Z standard 
semantics by adding subtyping. We make the convention that every object of 
MOD denotes a type. Every type in the sense of Z Standard becomes a maximal 
type in our topos theoretic semantics. 

Bindings over a set of identifiers V are modelled as the slice topos of MOD over 
V, denoted, by abuse of notation, as MOD. 

Refinement. In order to support partial specification, a formal approach must 
also offer strong support for refinement. This is the key of the success of applying 
model oriented methods to partial specification. The lack of space stopped us 
presenting the rich theory of relational refinement, see [12]. The data refinement 
concept is powerful enough to prove, for example, that the Z schema Move 
is refined by the schemas Open and Close (defined in the following section). 
One might ask how such a relational semantics might relate to the behavioural 
semantics required by process algebra; this is discussed in detail in [11]. 

5 Unification from Z 

In this section, the host category is a slice topos MOD over a set comprising all 
partial specification identifiers V. All category concepts we use in this section 
are internal [5, Section 8] in this topos. 

This section follows the set theoretic approach from [4]. We refer to [12, 4] 
for the definitions and properties of Z abstract datatypes (ADTs) and relational 
semantics. Consider the Z partial specifications (ADTs) A = (StA, InitA, { OpA}) 
and B = ( StB , InitB , { OpB}), where StA denotes the state space, InitA denotes 
the initialization of described state machine and the set of operations {OpA} 
specify all possible transitions. Z unification comprises three stages. 
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5.1 State Unification 

The hidden states of the two ADTs can be unified by pushout, using the amal- 
gamation operation developed in algebraic specification. 

The correspondence between two types C and D is given as a relation p : 
A <-> B . The internalization of relations plays a crucial role in unifying the states. 
The unified state can be viewed as a relation between extended states, namely 

totp — p U ( StA\ dom-p) x {J_a} U ( StB\ ran-p) x {1 ,b} 

This formula shows that state unification is basically relational, and the con- 
cept of correspondence plays a dominant role. Basically, every item in a partial 
specification must be considered as being related with an item from another 
partial specification. When the last item is not known, then a special element 
is introduced, the ‘unknown’, which is considered to be in correspondence with 
any other item from a different partial specification that is not already linked 
by the correspondence relation. 

Let C be a category and A,B,C,D G |C|. 

Given morplrisms fi, .... f n : A — > B(n > 1), and / : A — » C in C the following 
arrows gi, .... g n '■ C — > D and g : B — > D. chasing the diagram 

fi 

=$ B 

l g (RP) 

9 1 

=1 D 

9n 

in C are called relational pushout of (/i, ...,/„) and / if we have: 

(CC) gji = gi-f for every i = 1, ..., n and 

(U) For each object D' and morplrisms g\ g \, ..., g n with g' -fi = g[-f, ( i = 
1, ..., n) there is a unique morphism h:D—^D' s.t. h—g = g' and h-gi = g[ . 

Remark 1. For n = 1 the relational pushout is the standard pushout. 

Proposition 1. (Construction of relational pushouts) If C has finite coproducts 
and (standard) pushouts then C has relational pushouts. 

Corollary 1. MOD has relational pushouts. 

Important here is the concept of states consistent with respect to the corre- 
spondence relation. Not all states can be integrated in a consistent way; supple- 
mentary constraints are necessary to ensure consistency. 

The two state schemas StA=[a : A | PredstA ] and St 2 =[b : B \ PredstB ] are 
state consistent with respect to the correspondence relation p C A x B iff 

(a, 6)epO ( PredstA PredstB )■ 

Proposition 2. totp is the relational pushout of StA and StB via their projec- 
tions from p. 



A 

f 1 
C 
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Theorem 2. totp is the least developed refinement of the states consistent with 
respect to the correspondence relation p. 

For the first two viewpoints in our example, the correspondence p consists in 
the identification of True with Q and False with P. The state space of the OCL 
partial specification is essentially isomorphic as its add extra components (the 
counters) which are left unconstrained by the correspondence relation. 

5.2 Operation Adaptation 

As the new (unified) state was created, operations must be adapted to this. This 
is usually achieved using injective vocabulary morphisms. In this way all related 
techniques from the institution literature [17] get a fruitful application field here. 

For every state schema S, we consider an injective renaming verS and denote 
by revS the renaming from verS back to S . 

Every operation Op over the state space State is renamed (adapted) to an 
operation Op Ad on the unified state space StU = totp. 

Op Ad 

AStU 
Decl 

x £ ran verS 
x' £ ran verS 

letx == revS x; x' == revS x' • Pred 



Op 

AState 

Decl 



Pred 



5.3 Operations Unification 

As in Z, the precondition is only specified implicitly as the satisfiability of the 
operation, the operation itself serves as its postcondition. Conversely, we can 
specify the weakest postcondition of an operation Op as 

wpc Op == pre Op => Op 

For every operation Op, we have that Op = pre Op A wpc Op. 

In general, unification is given in a category having object operations, acting on 
a common state space, and arrows OpA — > OpB refinements given as pairs of 
implications pre OpA <= pre OpB and wpc OpA => wpc OpB. 

The categorical product acts contravariant on pre-conditions (i.e. it generates 
the disjunction of pre-conditions) and covariant on weakest post-conditions (i.e. 
it generates the conjunction of post-conditions) giving the following unification 
expression 



OpU. 

AStU 



(pre OpA V pre OpB) A (wpc OpA A wpc OpB) 
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Remark 2. The unification InitU of adapted initializations is their conjunction. 

Proposition 3. Operations unification is a limit. 

The following result, from [4], proves that our procedure provides the unifi- 
cation. The categorical version of data refinement involved will be presented in 
a subsequent work [8]. The proof in [4] is a set-theoretic one. 

Theorem 3. U = (StU , Init, {OpU}) is the least developed (data) refinement 
of A and B . 

Applying this procedure to the partial specifications of example from Section 
3, the resulting unification is described below. The reader might observe that no 
partial specification alone can be taken as the unification. 



State 

isopen : B 
oc, cc : Z 



Init _ 
State 1 



isopen' 
oc' = 0 
cc' = 0 



Close 

AState 

isopen 
-i isopen ' 
cc' = cc + 1 



Open 

AState 

-i isopen 

isopen' 

oc' = oc + 1 



Hello - 
AState 

isopen 

isopen' 



6 Conclusions 

The categorical approach to partial specification is a useful initiative. It provides 
a very rigorous foundation and helps to distinguish many facets and aspects of 
specification languages. Category theory helps us not only to discover the com- 
plexity of translations between formal specification languages, but also to explain 
it (in our example, by discovering the double dimension of SOS semantics) and 
to offer alternative solutions. 

It is necessary to distinguish between correspondences carrying specifications 
(CoCS) and semantic frameworks. CoCS adresses the partial specification only. 
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Semantic frameworks propose universal solutions, by embedding an important 
ammount of specification languages. These encodings might get very complex 
and aspects of the original specification might be lost during translation, af- 
fecting the unification and the possibility to provide constructive feedback. By 
contrast, CoCS does not prescribe any universal solution. It provides, for given 
partial specifications, a simplified common semantics called abstract correspon- 
dence. An AC acts like a common semantic framework, but relative to the partial 
specifications involved. Different partial specifications can have different associ- 
ated AC. The advantage of using category theory consists in the possibility of 
providing generic ACs: an abstract AC defined in categorical terms can be in- 
stantiated with several models, providing concrete ACs. The AC described in this 
paper models not only Z, but any specification language that can be axiomatised 
as specification frames (examples are given in [7]). 

Another relevant approach is the similarly sounding paradigm SCS: specifi- 
cation carrying code [1], The main differences between these approaches come 
from their different purposes. SCS main purposes are centred around code, as 
cryptography. CoCS is specialised on formal partial specification. However, the 
two paradigms make often use of the same formal tools, as category theory and 
refinement. 

We propose an extension of this paper to a full categorical framework for 
partial specification as further work. In [7] first steps were given, by formalizing 
categorically the (set theoretic) relational framework presented [6] . 

The detailed presentation of the proofs of results presented in this paper will 
appear in [8]. 

The most important conclusion that emerged from our formal experiments, 
points out the crucial role of correspondences in unification of specifications. 
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Abstract. This work contains both a theoretical development and a 
novel application of ideas introduced in [1] for using reflection in formal 
metareasoning. From the theoretical side, we extend the metareasoning 
principles proposed in [1] to cover the case of metatheorems about equa- 
tional theories which are unrelated by the inclusion relation. From the 
practical side, we apply the newly introduced metareasoning principles 
to formalize and prove semantic relations between equational theories 
used in formal specification. 



1 Introduction 

Intuitively, a reflective logic is a logic in which important aspects of its metalogic 
can be represented at the object level in a consistent way, so that the object- 
level representations correctly simulate the relevant metalogical aspects. More 
concretely, a logic is reflective when there exists a theory - that we call universal 
- in which we can represent and reason about all finitely presentable theories 
in the logic, including the universal theory itself [8,3]. As a consequence, in a 
reflective logic, metatheorems involving families of theories can be represented 
and logically proved as theorems about its universal theory. Of course, one of the 
advantages of formal metareasoning based on reflection is that it can be carried 
out using already existing logical reasoning tools. 

The use of reflection for formal metareasoning was first proposed in [1], both 
abstractly and concretely. Abstractly, it proposes a set of requirements for a logic 
to be used as a reflective metalogical framework. Concretely, it presents member- 
ship equational logic [12] as a particular logic that satisfies those requirements. 
In addition, it provides metareasoning principles to logically prove metatheo- 
rems about families of membership equational theories as theorems about its 
universal theory [9] . 

This work is both a development and an application of the reflective method- 
ology proposed in [1] for formal metareasoning using membership equational 
logic. First, we extend the metareasoning principles introduced in [1], In par- 
ticular, while [1] only considered metatheorems about membership equational 

* Research supported by Spanish MCYT Projects MELODIAS TIC2002-01167 and 
MIDAS TIC2003-01000, and CICYT Project AMEVA TIC2000-0701-C02-01. 
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theories which are related by the inclusion relation, our reflective methodology 
can also deal with metatheorems about theories which are unrelated with re- 
spect to inclusion. Thus, our extension increases significantly the applicability 
of the reflective methodology proposed in [1], as we show with the following 
case study. As is well-known, equational specifications can be related in different 
ways, and these relations can be informally formulated as metalogical statements 
of equational logic. The semantic relations between different equational specifica- 
tions are in fact key conceptual tools in the stepwise specification methodology, 
and different techniques and criteria have been proposed to metalogically prove 
them [10]. We show that some of these semantic relations can be formalized as 
theorems about the universal theory of membership equational logic and that 
they can be logically proved in a way that mirrors their corresponding proofs at 
the metalogical level. 

Organization. The paper is organized as follows. First, in Sect. 2 we introduce 
membership equational logic; the content of this section is standard material bor- 
rowed from other papers. Then, in Sect. 3 we formulate some semantic relations 
between membership equational specifications as metalogical statements, and in 
Sect. 4 we introduce metareasoning principles for metalogically proving them. 
Finally, in Sects. 5, 6, and 7 we present our reflective framework, and we put 
it to work. In particular, we show how a whole class of metalogical statements, 
that contains those in Sects. 3 and 4, can be represented and logically proved, 
using reflection, in membership equational logic; we include in an appendix a 
detailed example of this. 

2 Membership Equational Logic 

Membership equational logic is an expressive version of equational logic. A full 
account of the syntax and semantics of membership equational logic can be found 
in [2, 12]. Here we define the basic notions needed in this paper. 

A signature in membership equational logic is a triple fl = ( K , A, S ) with 
K a set of kinds, £ a AT-kinded signature £ = {£k 1 ...k n ,k}(k 1 ...k n ,k)eK xk , and 
S = {Sk}k&K a pairwise disjoint A'-kinded family of sets. We call Sk the set of 
sorts of kind k. The pair ( K , £) is what is usually called a many-sorted signature 
of function symbols; however we call the elements of K kinds because each kind 
k now has a set Sk of associated sorts, which in the models will be interpreted 
as subsets of the carrier for the kind. 

The atomic formulae of membership equational logic are either equations 
t = t' , where t and t' are A-terms of the same kind, or membership assertions 
of the form t : s, where the term t has kind k and s £ Sk . Sentences are Horn 
clauses on these atomic formulae, i.e. , sentences of the form 

V(xi , . . . , Xra ) . Ax A . . . A A n ■ V Aq , 

where each Ai is either an equation or a membership assertion, and each Xj is 
a A'-kinded variable. A theory in membership equational logic is a pair (17, E), 
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where E is a finite set of sentences in membership equational logic over the 
signature 17. We write (17, A) b <j> to denote that (17, E) entails the sentence <j>. 

We employ standard semantics concepts from many-sorted logic. Given a 
signature 17 = (K,E,S), an ft-algebra is a many-kinded 17-algebra (that is, a 
Abindexed-set A = {Ak}k£K together with a collection of appropriately kinded 
functions interpreting the function symbols in E) and an assignment that as- 
sociates to each sort s G Sk a subset A s C Ak- An algebra A and a valuation 
a, assigning to variables of kind k values in Ak, satisfy an equation t = tJ iff 
cr(t) = er(t , ). We write A, a \= t = t' to denote such a satisfaction. Similarly, 
A, a |= t : s holds iff er(t) € A s . 

Note that an 17-algebra is a A-kinded hrst-order model with function symbols 
E and a kinded alphabet of unary predicates { Sk}k&K ■ We can then extend the 
satisfaction relation to Horn and first-order formulae <f> over the atomic formulae 
in the standard way. We write A \= <j> when the formula <f> is satisfied for all 
valuations a, and then say that A is a model of <j>. As usual, we write (17, E) \ = <j> 
when all the models of the set E of sentences are also models of <p. As expected, 
the rules of inference for membership equational logic are sound and complete. 

Theories in membership equational logic have initial models. This provides 
the basis for reasoning by induction. In the initial model of a membership equa- 
tional theory, sorts are interpreted as the smallest sets satisfying the axioms 
in the theory, and equality is interpreted as the smallest congruence satisfying 
those axioms. Given a theory (17, E), we denote its initial model by Tq/ e . In 
particular, when A = 0 we obtain the term algebra Tq , and for X a AT-kinded 
set of variables the free algebra Tq(X). We write (17, E) |c± cf) to denote that the 
initial model of the membership equational theory (17, E) is also a model of <j), 
that is, that the satisfaction relation Tq/ e \ = cj> holds. 

3 Semantic Relations between Specifications 

The formalization and proof of certain semantic relations between equational 
specifications are important aspects of the algebraic specification methodology. 
In this regard, a classical notion is that of enrichment , which is a key conceptual 
tool in the stepwise specification methodology [10, 11]. We consider the following 
definition of the enrichment relation between membership equational specifica- 
tions. 

Definition 1. Let R = (17, E) and R' = (ft',E') be specifications, with ft = 
(K,E,S) and ft’ = (K ' , S ' , S'), such that R C R' componentwise. Let k be a 
kind in If, and let s be a sort in S k- Then R' is an s-enriclrment of R if and 
only if: 

1-a. Vf G Tq . R' h t:s => 3 1' G Tq. R h t ' : s A R' \~ t = t' 

1-b. Vf, t' G Tq. R\- t:s A Rf t' :s A R' \~ t = t' ==> R b t = t' . 

Note that our definition is slightly different from that in [10] - (1-a) and (1-b) 
correspond, respectively, to their notions of complete and consistent extensions 
- since we define the enrichment relation relative to a particular sort. The idea 
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captured by our definition is that each ground term in the specification R' having 
the sort s can be proved equal to a ground term of the specification R having 
the sort s, and also that R' does not impose new equalities on ground terms of 
sort s of the specification R. These properties correspond, respectively, to the 
no junk and no confusion properties in Burstall and Goguen’s terminology. 

The enrichment relation assumes an inclusion between the given specifica- 
tions. There are other semantic relations, however, that do not require such an 
inclusion. Consider, for example, the specifications INT\ and INT 2 below. They 
are presented using Maude syntax [5, 6], where operators, variables, membership 
axioms, and equations are introduced, respectively, with the keywords op, var, mb 
(or cmb for the conditional case), and eq. The Maude system implements mem- 
bership equational logic (and rewriting logic) and can infer kind information 
automatically; however, for increased clarity, we have explicitly named kinds, 
with their associated sort lists inside square brackets following the kind’s name. 
The specifications INT ] and INT 2 are clearly related since both specify the in- 
teger numbers - and, in that sense, they are interchangeable -, but neither INT 1 
is included in INT 2 , nor INT 2 in INT\. 



fmod INTI is 

kind Num[Neg, Nat, Int] . 
op 0 : -> Num . 
op s : Num -> Num . 
op p : Num -> Num . 
var N : Num . 

Nonpositive numbers 
mb 0 : Neg . 

cmb p(N) : Neg if N : Neg 
Natural numbers 
mb 0 : Nat . 

cmb s(N) : Nat if N : Nat 
Integers 

cmb N : Int if N : Neg . 
cmb N : Int if N : Nat . 
endfm 



fmod INT2 is 
kind Num [Int] . 
op 0 : -> Num . 
op s : Num -> Num . 
op p : Num -> Num . 
var N : Num . 

Integers 
mb 0 : Int . 

cmb s(N) : Int if N : Int 

cmb p(N) : Int if N : Int 

eq p(s(N)) = N . 

eq s(p(N)) = N . 

endfm 



We propose the following definition for this particular relation between member- 
ship equational specifications. For the sake of simplicity, we restrict our definition 
to specifications with a common set of kinds. 

Definition 2. Let R = (17, E) and R' = (17', E') be specifications, with 17 = 
(K,E,S) and 17’ = (K, S ' , S'). Let k be a kind in K, and let s be a sort in 
Sk fl S' k . Then R and R' are s-interclrangeable if and only if: 

2-a. Vf £ Tq. R\- t: s => 3 t' £ Tq . R' b t' : s A R b t = t' 

2-b. \/t,t' £Tq ■ R' F t : s A R' b t' : s A R h t = t' => R' b t = t' 

2-c. Vf £ Tq . R' \~ t: s => 3f' £ Tq. R b t ' : s A R' \~ t = tl 

2-d. Vf, t' £ Tq. R \- t : s A R b t' : s A R' b f = t' => R b f = t' . 
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The idea captured by the above definition is that each ground term in the 
specification R! (resp. R) having the sort s can be proved equal to a ground term 
of the specification R (resp. R') having the sort s, and also that R' (resp. R) 
does not impose new equalities on ground terms of sort s of the specification R 
(resp. R'). 

Now, note that to prove properties (1-b), (2-b), and (2-d) we need, in general, 
to examine the form of the axioms in R and R! . But to prove properties (1-a), (2- 
a), and (2-c) we can use inductive techniques. In fact, an inductive reasoning 
principle is proposed in [2] to logically prove property (1-a). However, the lack 
of an inclusion between R and R' invalidates the use of this principle for proving 
properties (2-a) and (2-c). We will propose in Sect. 4 an inductive reasoning 
principle ( ind + ) to metalogically prove these properties, and we will show in 
Sect. 7 how this principle can be transformed, using reflection, into an inductive 
reasoning principle (ind+) to logically prove them. 

4 An Inductive Principle 

for Metalogically Proving Semantic Relations 

In order to provide a simpler and more compact formulation, and soundness 
proof, of an inductive principle ( ind + ) for metalogically proving semantic rela- 
tions between equational specifications, we begin by extending the definitions 
of terms, atomic formulae, and entailment relation for membership equational 
logic. Basically, these extensions allow us to metareason on equivalence classes of 
terms, instead than on concrete terms, which is essential for metareasoning about 
families of theories which are unrelated with respect to inclusion. However, this 
change of logical framework is only transitory. We will show in Sect. 7 how the 
inductive principle ( ind + ) can be transformed, using reflection, into an inductive 
principle ( ind + ) for logically proving, in standard membership equational logic, 
semantic relations between equational specifications. Of course, since our final 
goal is to provide principles for carrying out formal metareasoning, we are inter- 
ested in ( ind + ) rather than in ( ind + ), but we introduce the latter as a technical 
device to simplify the presentation and proof of the former. 

In what follows, let C7Z be the class of finite multisets of finitely presentable 
theories with a common, nonempty set of kinds 7Z = {Ri}i = {(Pi, -E))}ie[i..pb 
with each fi t = (K, Si, Si). We consider multisets instead of lists or sets for 
technical reasons: it simplifies our definition of the inductive principles ( ind + ). 

Definition 3. Given 1Z = {Ri}i = {(P*, £?i)}ie[i.. p ] £ CTZ, with each f2i = 
(K, Z), Si), we define the set TjffX) of (f2i,7Z) -terms with K-kinded variables 
in X as follows: 

— c £ (T]f(X)) k iff c £ (Si) A,fc, k £ K, where A denotes the empty sequence 
of kinds; 

— x £ (T^(X)) k iff x £ X k , k £ K; 

- f(h,...,t n ) £ (T%(X)) k iff f £ (17 j )fc 1 ...fc B) fc, andtj £ (T^(X)) kj , for 
j = n, 

- e (T%(X)) k iff Rj £1Z and t£ (T%.(X)) k . 
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As we will formalize in Def. 5 below the intended meaning of the term [t] R j, in 
the particular case that t £ To. , is the equivalence class of the terms provably 
equal to t in the theory Rj. 

Definition 4. Given TZ = {Ri}i = {(Gi,Ei)} ie u p -\ £ CTZ, with each Gj = 
(K, Si, Si), an atomic (Gi,TZ) -formula is either an equation t = t' , where t and 
t' are (Gi,TZ)-terms of the same kind, or a membership assertion of the form 
t:s, where the ( Gi,TZ)-term t has kind k and s £ (S'i)fc. 

Definition 5. Given TZ = {Ri}i = {(!?,, [i..p] £ C TZ, with each G t = 

(K, Hi, Sf), for all theories Ri £ TZ and atomic (G t ,TZ) -formulae <j>, we recur- 
sively define the entailment relation b K as follows: 

— if there is a position p in <f> (for an appropriate definition of positions in 
atomic formulae), and a term t £ (Tn.)k, with Rj £ TZ, such that [f]#. 
occupies position p in <f>, then 

Ri b K f iff 3 1' £ (Tn t )k H (Tn } )k- (Ri b U <t>[t'] P A Rj b t = t') , 

where <j>[t'] p is the replacement operation of the term t' inside the atomic 
formula 4> at position p; 

— otherwise, Ri b K (f> iff Ri b <f>. 

According to this definition, a theory Ri entails an atomic ( , 7?.)-formula, <j>if<j> 
can be proved in Ri after recursively replacing all occurrences of terms [t] » , such 
that t £ Tq . , with appropriate ground terms in the corresponding equivalence 
classes. 

Remark 1. Given TZ = {Ri}i = {(Gi, Ei)} i€ .[i p ^£CTZ, with each Gi = (K, Si, Sf), 
for all theories Ri,Rj £ TZ, atomic (f?j, 72.)-formulae <f>(x), with free variable x 
of kind k, and terms t,t' £ (Tn^k H (To.)fc, the following statements hold: 

— if Rj b t = t', then R t b K <j)([t] Rj ) iff A, b K (t>([t'] Rj ); 

— Ri b K iff Ri \~ n (t>([t\ Ri )-, 

— if R i b K (j>(t) then R t b K (f>([t\ Rj )-, 

— if Ej C Ej, then Ri b K <j>(t) iff Ri b K <t>([t\ Rj ); and 

— if Ej does not include any equations, then Ri b K <f>(t) iff Ri b K (f>([t\ Rj ). 

For example, using these extended definitions of terms, atomic formulae, and 
entailment relation for membership equational logic, we can express, in a simple 
and compact way, property (2-c) with respect to INT 2 and INT\ by the following 
metalogical statement: 

Vf £ (TiNT 2 )Num- (. INT 2 b t:Int=* INTi b 1 [t] INT2 : Int ) , (1) 

where X is the multiset {INT i, INT 2 }. 

We are now ready to prove in Prop. 1 below an inductive principle (ind + ) 
for metalogically proving metatheorems about finite multisets of theories TZ = 
{Ri}i = {(Gi, Ei)} ie [i p ] in C TZ. Since this proposition is rather technical, we 
informally advance its content. 




78 



Manuel Clavel, Narciso Martf-Oliet, and Miguel Palomino 



— The inductive principle ( ind + ) can be applied to metalogical statements 
of the form: “for all terms 1 of a sort s in a membership equational the- 
ory Ri in IZ , some property P holds.” Here, P is a Boolean expression, 
bexp(Bi , . . . , B p ), whose propositional variables are instantiated with meta- 
logical statements of the form: “an atomic (f2j, 7£)-formula <j>([t\ R .) holds in 
Rj” with respect to our extended definition of the entailment relation. For 
example, the metalogical statement (1) belongs to the class of metatheorems 
to which our inductive principle can be applied. 

— The inductive cases generated by the inductive principle ( ind + ) are directly 
derived from the inductive definition of the sort s in the membership equa- 
tional theory Ri. Therefore, our inductive cases mirror the inductive cases 
generated by the usual structural induction principle for membership equa- 
tional theories. For example, the three inductive cases generated by ( ind + ) 
when applied to the metalogical statement (1) correspond to the three cases 
in the inductive definition of the sort Int in INT 2 : namely, 0 is an Ink, s(n ) 
is an Int, if n is an Int ; and p(n) is an Int, if n is an Int. 

In what follows, given a term u G T]f(X), we denote by u(x i, . . . , x n ), or just 
u(x), the fact that the variables in u are in the set x = {aq, . . . , x n } C X. Thus, 
given a set {ti, . . . ,t n } of metavariables, we denote by u(t) the simultaneous 
replacement of Xi by ti in u, for i = 1, . . . , n. Similarly, given an atomic formula 
4>{x) with free variables in x, we denote by (f>(i) the simultaneous replacement 
of Xi by ti in <f>, for i = 1, . . . , n. 

Proposition 1. Let IZ = {Rf}i = {(fli, -Ei)}ie[i.. p ] be a finite multiset of theo- 
ries in CIZ, with each f2i = ( K , Xi, Si). Let s be a sort in some ( S e )k , e € [l..p] 
and k € K , and let C[/{ ejS ] = {C\, . . . , C n } be those sentences in E e that specify 
s, i.e., those Ci of the form 

V(aq, . . . , x ri ). Ai A . . . A A qi => A 0 ,, (2) 

where, for 1 < j < r^, Xj is of kind k , . , and for some term w of kind k, Aq is 
w:s. 

Then, for all finite midtisets of atomic formulae, {</ , z( a 0}/e[i..pl> with each 
4>i{x) an atomic (I2i,IZ) -formula with free variable x of kind k, and Boolean 
expressions bexp, the following metalogical statement holds: 

■01 A ... A Ipn (3) 

=> Vt G (Thjfc. ( R e I ~t:s => bexp(R\ \- n ([t] ) , . . . , R p <^ P ([t]fiJ)) , 

where, for 1 < i < n and Ci in E e of the form (2), ifi is 

Vti G {Tn e ) kii . . . Vt rj G {Tn e )k iTi ■ M-iP A ... A => [^-o]^ 

and, for 0 < j < qi, 

M .1# A / beX P ( R 1 ^l([ U (i)]fle)>" -1 R P ^ ^p([ W (i)]fla)) if A 3 = U:S 

R \ R e b Aj (t) otherwise. 
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The metalogical statement (3) introduces an inductive metareasoning principle 
(ind + ), where each ipi corresponds to an inductive case and the top line in the 
definition of [A$ provides the corresponding induction hypotheses. 

Proof (soundness). Assume that ipi A • • • A ip n holds. We must prove that 

Vi G (Tfijfc. ( R e b t.:s => bexp{R\ <f>i([t\ Re ), . . . ,R P <t> p ([t] Re ))) 

also holds. Let t G {Ta e )k be a term such that R e b t : s; we proceed by 
structural induction on this derivation. If R e b t : s, then there exists a sentence 
Ci in E e of the form V(xi, . . . , x Ti ). A\ A . . . A A qi ==>■ A 0 , where, for 1 < j < ri, 
Xj is of kind fc, , and for some term w of kind k, Aq is w:s, and a substitution 
a : {x \, . . . , x Ti } — > Tf/ e , such that 

— R e b t = cr(w), and 
-Re b cr (Aj), for 1 < j < Qi. 

In this case, we must prove that bexp(R\ b K <j>i ([t]ij e R p b K 4> p ([t\ Re )) 
holds, under the inductive hypothesis that, for 1 < j < q. n if Aj = Uj : s, 
then bexp (R\ b K fii([a(uj )) Re ), . . . , R p \~ K <j> P ([<r(uj)] Re )) holds. Since, by as- 
sumption, ifi holds, then it also holds [Afi^ A ... A [. A qi ]£ =^> [A 0 ]^, where, for 
0 < j < qu 



i a i# a f bexp(R 1 (j) 1 ([a(uj)} Re ),...,R p \-' R (f) p ([a{uj)) Re )) ifAj=Uj:s 
\R e \- cr(Aj) otherwise. 

Note then that, for 1 < j < qi, 

- If Aj = ( Uj\s ), then [Aj}( holds by induction hypothesis. 

— If Aj ^ ( Uj\s ), then [Aj]^ holds by assumption. 

Hence, [A 0 ]£, that is, bexp(Ri b K fi\([a(w)) Re ), . . . ,R P \~ K fi p ([a(w)] Re )), also 
holds. Finally, since R e h t = cr(w), by Rem. 1, we have that bexp(R\ b K 
f>i([t} Re ), ...,R p \~ n fi P ([t] Re )) as required. □ 

As a final remark, note that a case analysis metareasoning principle ( case + ) 
can be introduced in a way entirely similar to ( ind + ), except of course for the 
definition of [Aj]$, that will be as follows (see [7] for more details): 

Mi# a f bexp (i?i b fa ([u(t)] Re ),...,R p b <f P {[u(t)) Re )) if j = 0 
J \R e \- Aj(t) otherwise. 

5 Reflection in Membership Equational Logic 

A logic is reflective when there exists a universal theory in which we can repre- 
sent and reason about all finitely presentable theories in the logic, including the 
universal theory itself [8,3]. A universal theory MB-META for membership equa- 
tional logic was introduced in [9] , along with a representation function (_ b _) 
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that encodes pairs, consisting of a finitely presentable membership equational 
theory with nonempty kinds and a sentence in it, as sentences in MB-META. The 
signature of MB-META contains constructors to represent operators, variables, 
terms, kinds, sorts, signatures, axioms, and theories. In particular, the signature 
of MB-META includes the sorts Op, Var, Term, TermList, Kind, Sort, and Theory 
for terms representing, respectively, operators, variables, terms, lists of terms, 
kinds, sorts, and theories. In addition, it contains three Boolean operators 

op _ : : _in_ : [Term] [Kind] [Theory] -> [Bool] . 
op _:_in_ : [Term] [Sort] [Theory] -> [Bool] . 

op _=_in_ : [Term] [Term] [Theory] -> [Bool] . 

to represent, respectively, that a term is a ground term of a given kind in a 
membership equational theory, and that a membership assertion or an equation 
holds in a membership equational theory. Note that here, and in what follows, 
we use Maude’s convention for naming kinds: kinds are not named but denoted 
using the name of their sorts enclosed in square brackets. 

The representation function (_ b _) is defined in [9] as follows: for all finitely 
presentable membership equational theories with nonempty kinds R and atomic 
formulae <fi over the signature of R, 

p. , _a f (t : s in R) = true if <j> = ( t:s ) 

\ (t = t' in R) = true if <p = (t = t ') , 

where (_) is a representation function defined recursively over theories, signa- 
tures, axioms, and so on. Under this representation function, a term t is rep- 
resented in MB-META by a ground term t of sort Term, a kind k is represented 
by a ground term k of sort Kind, a sort s is represented by a ground term s of 
sort Sort, and a theory R is represented by a ground term R of sort Theory. In 
particular, to represent terms the signature of MB-META contains the constructors 

op _ [_] : [Op] [TermList] -> [Term] . 

op nil : -> [TermList] . 

op : [TermList] [TermList] -> [TermList] . 

and the representation function (_) is defined as follows: 

{ c if t = c is a constant 

x if t = x is a variable 

fltl, ■■■ Jn\ if t = f(tl, ■ . • , t n ). 

For example, the term s(0) of kind Nurn is represented in MB-META as the term 
s[0] of sort Term. 

The following propositions state the main properties of MB-META as a univer- 
sal theory [9] : 

Proposition 2. For all finitely presentable membership equational theories with 
nonempty kinds R = (f2,E), with ft = ( K,E,S ), terms t in Tq, and kinds 
keK, 

t € (T n ) k MB-META b (t : : k in R) = true . 
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Proposition 3. For all finitely presentable membership equational theories with 
nonempty kinds R = (17, E), with ft = ( K , E, S), kinds k € K, and ground terms 
u of the kind [Term] , if 

MB-META b (u :: k in R) = true , 

then there is a term t £ such that t = u. 

Proposition 4. For all finitely presentable membership equational theories with 
nonempty kinds R = (ft,E), with ft = ( K,E,S ), terms t in ( Tq)^ and sorts s 
in Sk, 

R b t : s MB-META b (f : s in R) = true. 

Similarly, for all terms t, t' in ( Ta)k , 

Rft = t' MB-META b (t = F in R) = true . 



For example, 



MB-META b (p(s(p(0))) : Int in INT2) = true , 



but 

MB-META \f (p(s(p(0))) : Int in INTI) = true . 



6 Reflection in Extended Membership Equational Logic 



To represent and reason about our extended definition of entailment relation, we 
define a new theory MB-META = that extends the universal theory MB-META with 
a binary operator 

op _in_ : [Term] [Theory] -> [Term] . 

ceq ft in R) = it' in R ) if ft = t' in R) = true . 



to represent the equivalence class of a term in a membership equational theory. 



Proposition 5. For all finitely presentable membership equational theories with 
nonempty kinds R = ( ft,E ), with ft = (K,E,S), and terms t, t' in (Tn)k, 
keif, 

R\-t = t' MB-META = b (t in R) = (t' in R) . 

Using this operator, we can now define a representation function (_) for terms 
in the extended class, which satisfies the expected property, as shown in Prop. 6 
below. Let 7 Z = {Ri}i = {(/?*, a finite multiset of theories in C1Z. 

Then, for all terms t € T^(X), 






c if t = c is a constant 

x if f = x is a variable 



f_lh , ,f„] if t = f(ti, 

{t' in R) if t=\t']n. 



(4) 
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Proposition 6. Let TZ = = {{&i, Ei)}ie\i.. p ] be a finite multiset of the- 

ories in CTZ, with each Pi = (K, Si, Si). Then, for all theories Ri £ TZ, terms 
t £ (T^-)k and sorts s in ( Si)k , k £ K, 

Ri b K t : s <=> MB-META~ b (t : s in Ri) = true. 

Similarly, for all terms t,t' £ (T]f) k , k £ K, 

Ri b n t = t' MB-META= b (t = F in R)) = true . 

Proof. This proposition is a corollary of Props. 4 and 5. □ 

7 An Inductive Principle 

for Logically Proving Semantic Relations 

We are now ready to prove in Prop. 7 below the main technical result in this pa- 
per, namely, that there is a class of metatlreorems about membership equational 
logic theories which can be represented and logically proved as theorems about 
the initial model of the membership equational theory MB-META = . As a corollary 
of this proposition we will obtain an inductive reasoning principle ( ind + ) for log- 
ically proving metatheorems about families of membership equational theories. 

In order to simplify the presentation of the upcoming material, we introduce 
here some additional notation. Let 7 Z = {Ri}i = {(Pi, £'i)}ie[i..p] be a finite 
multiset of theories in C7Z, with each Pi = ( K , Si, Si). For all theories Ri £ 7 Z 
and terms t £ T'q. (A), we denote by t lx] the reflective representation of t defined 
in (4), except that now variables x £ X are replaced by variables x [x] = x of the 
kind [Term] and we denote by X the set X = {x lx] \ x £ X}. In addition, 
for all theories Ri £ 7Z, and membership assertions t :s, with t in T^\X) and s 
in some (Si) k , 

t : s = (t : s m Ri) = true , 
and, similarly, for all equations t = t' , with t, t' in T^(X), 

t = t = [t = t m Ri) = true . 

We can now define a representation function for metalogical statements, 
which satisfies the expected property, as shown in Prop. 7 below. Let 1Z = 
{Ri}i = {(Pi, Ei)}ie[i.. P ] be a finite multiset of theories in C1Z, with each 
Pi = (K, Si, Si). Let {k\, . . . ,k n } be a finite multiset of kinds, with each ki 
in K , let x = {xi, . . . , x n } be a finite set of variables, with each Xi of kind ki, 
and let r be a metalogical statement of the form 

VL £ (T ni ) kl . . . . Vt„ G ( T 0n ) kn ■ bexp(Ri b K ^(t), . . . , R p b K , (5) 

1 The key difference between t and 7 [AI is that 7 is a ground term of sort Term, whereas 
7 |A1 is a term of kind [Term] with variables of the kind [Term] . 
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where each fn(x) is an atomic (i7j, 7£)-formula with free variables in x. Then, 

T = \/x\. . . .Vx n . (((aq :: k\ in R\) = true A • • • A (x n :: k n in R n ) = true) 

=> bexp{(j>i{x) lRl ' x \ . . . , ^p(f) [Rp ' x1 )) , 

where {aq, . . . , x n } are now variables of the kind [Term] . 

Note that the class of metalogical statements of the form (5) includes, for 
example, all instances of the properties (1-a) in Def. 1, and (2-a) and (2-c) in 
Def. 2. In particular, the metalogical statement (1) is represented in MB-META = 
as the formula 

VN.((N :: Num in INT2 = true) 

=> (N : Int in INT2 = true) => ((N in INT2) : Int in INTI = true)) , 

where N is a variable of the kind [Term] . 



Proposition 7. Let TZ = {Ri}i = {(f2i,Ei )} ie n p i be a finite multiset of theo- 
ries in C1Z, with each i?i = (K, 27$, Si). For all metalogical statements t of the 
form (5), t holds iff MB-META = f^r. 

Proof. We first prove the (=>)-direction of this proposition. Suppose that r holds. 
Let cr : {aq, . . . , x n } — > 2mb-meta= be a substitution such that, for 1 < i < n, 

MB-META = |cs (cr(aq) :: fc; in Rf) = true . (6) 

We must prove that 

MB-META = \^l<t (j)exp((f>i(x) 1 \ . ... , (j) p {x) [ P ' ')^ . 

Note that, since (cr(x i ) :: ki in Ri) is a ground term, (6) implies 
MB-META~ |= (cr(aq) :: ki in Ri) = true, 



which, by completeness of membership equational logic, implies 
MB-META~ b ( <r(aq ) :: ki in Rf) = true . 



Thus, by Prop. 3, we know that, for 1 < i < n, cr(aq) = Wi for some Wi € (Tfojfc,. 
Note then that 



cr 



(f) 



[i?l ,x ] 




bexp(4>i(w) 



[Bl, 1 



• ■ ,(fp{w) lRp ’ J ), 



and that, by Prop. 6, for 1 < l < p, Ri b K fn[w) iff MB-META b f>i{w) [ 1 \ 
Since we are assuming that bexp{R\ b K fix (w), . . . ,R P b K 4> p {w)) holds, then 

MB-META = b bexp(<j>i(w) 1 (j> p (w) [ *”'), 



and, by soundness of membership equational logic, 

MB-META = bexp(<f>i(w) 1 ', . . . , (f> p (w) 1 ’”'), 



as required. 
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The proof of the (4=)-direction is similar. In particular, consider for any terms 
{tui, . . . , w n } the substitution a : {xi , . . . , x n } — > 7mb-meta= given by cr(xi) = vh, 
for 1 < i < n. □ 

As corollaries of Prop. 7 we can prove the reflective versions of Rem. 1 and 
Prop. 1, which we will denote, respectively, as Rem. 1, and Prop. 1. Both are 
obtained by replacing each metalogical statement <f> in Rem. 1 and Prop. 1 by 
its logical representation 4> in MB-META = . Of course, this is key for our purposes, 
since it automatically gives us an inductive reasoning principle (mrf+), and a case 
analysis reasoning principle (case+), for proving metalogical statements about 
membership equational theories represented as logical statements in MB-META = . 
Moreover, since Rem. 1 and Prop. 1 mirror their metalogical counterparts, the 
metalogical proofs based on the latter will also be mirrored by the logical proofs 
based on the former. As an example of this, we logically prove in the appendix, 
using the induction principle ( ind + ), that INT 2 satisfies property (2-c) with 
respect to INT\. 

8 Conclusion 

The work presented is based on the ideas proposed in [1] for formal metarea- 
soning using reflection. Here we extend the metareasoning principles introduced 
in [1], increasing their applicability as we show in a case study. The reader can 
find in [1] a detailed discussion on tradeoffs and limitations of reflective meta- 
logical frameworks, and a survey of related work. 

One of the advantages of formal metareasoning based on reflection is that 
it can be carried out using already existing logical reasoning tools. Our experi- 
ence shows also that the logical proofs of metatheorems using reflection mirror 
their standard metalogical proofs. In this regard, we plan to use our results to 
extend the ITP tool [3,4], which is an interactive inductive theorem prover for 
membership equational theories, with metareasoning capabilities, so that it can 
be used, for example, as a methodological tool for software development. 
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Appendix 



We show how Fact 1 below, that is, the representation of the metalogical state- 
ment (1) as a logical statement about the initial model of MB-META = , can be 
logically proved using the inductive principle (ind + ), along with the reflective 
properties of membership equational logic. Our proof mirrors at the logical level 
the metalogical proof of (1), that we omit here for the sake of space limitations; 
this proof can be found in [7]. 

Fact 1. 

MB-META = *£± VN.(N :: Num in INT2 = true 

=> (N : Tnt in INT2 = true) =>■ ((N in INT2) : Tnt in INTI = true)) , 



where N is a variable of the kind [Term] . 
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Proof. By ( ind + ), we can prove the theorem by showing: 

MB-META = ((0 in TfFT) : Tnt in INTI = true) (7) 

A VN.(N :: Num in INT2 = true 

==>• ((N in TfFT) : Tnt in INTI = true) (8) 

==> ((s [N] in TfFT) : Tnt in TfFT = true)) 

A VN.(N :: Num in INT2 = true 

==> ((N in TfFT) : Tnt in TfFT = true) (9) 

=>■ ((p [N] in TfFT) : Tnt in TfFT = true)) , 

where N is a variable of the kind [Term] . Note that (7) holds by Prop. 6 (using 
soundness of membership equational logic). Regarding (8) and (9), their proofs 
are similar; we show here only the proof of (8). It is a fact 2 that, (8) holds if 

MB-META = VN.(N :: Num in TfFT = true =>■ (N : Tnt in TfFT = true) (10) 
=> ((s [N] in TfFT) : Tnt in TfFT = true)) , 
which, by Rem. 1, is equivalent to 

MB-META = VN.(N :: Num in INTI = true ==> (N : Tnt in INTI = true) (11) 
=>■ ((s [N in TfFT] in TfFT) : Tnt in TfFT = true)) . 

To prove (11) we can use again ( ind + ), and reduce its proof to showing: 

MB-META = ^ VN.(N :: Nurn in INTI = true =► (N : Nat in TfTT = true) (12) 
=> ((s[N in TnTT] in TfFT) : Tnt in TfFT = true)) 

A VN.(N :: Nuin in TfFT = true =>■ (N : Neg in TfFT = true) (13) 
=> ((s[N in TnTT] in TfFT) : Tnt in TfFT = true)) 

The proofs of (12) and (13) are similar; we show here only the proof of (13). 
By (case+) and Rem. 1, we can reduce proving (13) to showing: 

MB-META = (s [0] in TfFT) : Tnt in TfFT = true (14) 

A VN.(N :: Num in INTI = true =£■ (N : Neg in INTI = true) (15) 
=> (('s[p[N]] in INT2) : Int in INTI = true)) 

Note that (14) holds by Prop. 6 (using soundness of membership equational 
logic). Regarding (15), let a : {N} — > T mb _ meta = be a substitution such that 
(cr(N) :: Num in INTI = true) and (cr(N) : Neg in INTI = true) hold in 
the initial model of MB-META = . Thus, by Prop. 3, er(N) = N for some term 
N of kind Num, and, by Prop. 4, INT i b N : Neg. Finally, note that, since 
INT 2 h s(p(N)) = N, then, by Prop. 6 (using again soundness of membership 
equational logic), 

MB-META = ^ (s[p[7V]] in TfFT) : Tnt in TfFT = true) . 



2 This fact is an instance of the reflective counterpart of a general metareasoning 
principle for reducing metalogical statements to a form such that ( ind + ) can be 
applied to them. For the sake of space limitations, we omit here the proposition that 
states this principle, and its proof, that can be found in [7]. 
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Abstract. The problem addressed in this paper is the formal verifica- 
tion of temporal properties in the presence of unbounded data types. 
In that framework, state of the art model-checkers use reduction tech- 
niques, e.g. abstraction, to compute finite counterparts of the systems 
under consideration. The method we present integrates a model-checker 
for the modal ^-calculus with a theorem prover, it processes unbounded 
systems without having to reduce them. 



1 Introduction 

In software engineering, as in hardware design, there is a crucial need for formal 
verification methods. Testing is one of the main software verification techniques 
used in practice. However, an exhaustive testing of all execution paths is prac- 
tically infeasible, testing can thus never be complete and cannot guarantee the 
absence of errors. Formal methods allow an early integration of verification in 
the development process, and provide more reliable techniques. They are meant 
either to check the functionality of the system or to verify properties. 

This paper addresses the problem of formally verifying temporal properties of 
high-level specifications that take into account unbounded domains, for instance 
with integer variables. Keeping these variables under their numeric form engen- 
ders an infinite state space, classical model-checking techniques do not apply. 
Even assuming an encoding that induces a fixed size, model-checking techniques 
suffer from the state space explosion problem (as the size of the data increases, 
the state space of the system increases exponentially). Many existing model- 
checkers perform either explicit or symbolic enumerations of the reachable states 
of the system, using BDD-based representations and their various enhancements. 
For systems with arithmetic data or for real-time systems with several clocks, 
state space reduction techniques have to be applied to get tractable problems. 
Various solutions have been proposed, such as the consideration of uninterpreted 
functions [1, 2], the use of abstraction techniques [3-5], the construction of region 
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graphs [6], the computation of partial order reductions [7, 8], or the exploitation 
of symmetries [9] . There are various disadvantages with techniques like abstrac- 
tion: difficulties to build the abstraction, necessity for validating it (do the prop- 
erties that hold at the abstract level still hold at the concrete level?), difficulties 
to reason on liveness properties, to express counterexamples, etc. 

Deductive approaches implemented in theorem provers do not impose a limit 
on the size or the complexity of the system and give the opportunity to express 
and to verify properties over infinite domains. For instance, the simple induction 
technique is efficient to reason on data types like natural numbers. Combination 
of model- checking and theorem proving allows to exploit their complementary 
strengths to verify large or infinite systems [10]. Among these works, we can 
mention [11] that proposes a combination of different proof tools, among them 
the model-checker SMV [12] and the theorem prover HOL [13], through a variety 
of strategies. In [14] , an induction mechanism for natural numbers is integrated 
in the proof assistant of SMV. The inductive proof uses an abstraction that 
partitions the natural numbers into a finite number of intervals. A finite model 
is obtained, that can be processed fully mechanically with SMV. 

Our method proposes a combination of a model-checker for the modal v- 
calculus with a theorem prover, first theoretical results were reported in [15]. It 
does not assume any specific encoding of the variables, does not require any state 
space reduction, and is not limited to combining model-checking and theorem 
proving techniques via strategies. The algorithm realizes a classical fixed-point 
computation, and calls on the theorem prover at specific and well-identified 
steps to process by deduction arithmetic conjectures. This paper presents the 
methodology and the tool under development. 

After presenting in Section 2 the characteristics of the systems that we con- 
sider and the foundations of our model-checker, we describe the tool and detail 
the algorithm in Section 3. Section 4 proposes some related works, and then we 
conclude with a description of our ongoing and future work. 



2 Model-Checking without Abstraction 

2.1 Modelling the Systems and Their Properties 

Our method is inspired from the one proposed by G.Winskel in [16], which is 
an algorithm for checking whether a state of a labelled transition system (LTS) 
satisfies a property in the modal //-calculus [17]: the models under consideration 
are of the form ( Proc , {A |a € labels}, V), where Proc is a nonempty finite set 
of processes (states) and V is a function from basic assertions a to the subsets 
V (a) C Proc of processes satisfying them. 

The models we consider allow to describe more elaborate systems: transition 
systems where transitions are not labelled by atoms of a finite set, but by pairs 
of the form condition / assignments , and condition and assignments can han- 
dle unbounded data types. More precisely, the models are tuples of the form 
(S, V, I, O, C, A, S 0 , P 0 ), where 
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S' is a finite set of symbolic states, 

V is a set of variables, 

/ and O are sets of inputs and outputs that carry boolean or arithmetic data, 
£ is a set of labels (transition conditions), that are formulas of the predicate 
calculus without quantifiers, 

A is a set of assignments of the form v <— exp(v\, ..., v n ); they correspond to 
the actions that are performed on the transitions, and will be interpreted 
hereinafter as equalities v = exp(v\, ...,v n ) 

-> C S x (£ x 2 a ) x S denotes the transition relation, a notation of the form 
a/ a is used to label the transitions, 

So £ S is the initial state, and Po are the properties that hold in Sq. 

Example. Let us illustrate this definition with a simple version of a cash with- 
drawal system, see Fig. 1 (transition labels of the form a/— mean that there is 
no assignment). S contains 6 symbolic states, V = {code, ok, n }, I = { inc , cc, 
codin, take}, and O = {outc, keep}. The inputs inc and take are true resp. when 
the card is entered and withdrawn, cc is the card code, codin is the submitted 
code. The outputs outc and keep indicate resp. that the card can be withdrawn 
or that the machine keeps it. The initial state is Sq, the associated property 
is outc = false. If the customer gives the right code before the third attempt 
(included), he is allowed to retrieve his card; otherwise the card is kept. 



(inc - true) / 7V code - codin 




Fig. 1 . Behaviour of a cash machine 



Our language of assertions contains two modal operators <0 and □ (their 
intuitive meaning is close to the one of the operators introduced in [17]) and a 
greatest fixed-point operator inspired from the one of [16]: 

A ::=/ \ T\F\^A\A 0 AA 1 \AoVA 1 \ {if) A \ ty\A \ X \ vX{r}A 

where / represents “atomic” formulas (formulas without propositional connec- 
tive, but that can involve predicates symbols), ip £ £, and r is a list of the form 
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(7*1, p\), (r„, tfin), Ti £ S, (fii is a formula made of subformulas of A! UC where 
A! is A where the assignments are interpreted as equalities. 

As in [ 16 ] the semantics [A] of these assertions is given w.r.t. an environment 
function p, but it is also related to a formula p that represents the conjunction 
of the properties that are known to be true in the current state: [A] p>v , is the 
subset of S in which p => A. The definition of this semantics is as follows: 



I/W = 




if => f, 

otherwise 



p => f means that the conjunction of the formulas that are known to be true is 
sufficient to deduce that / is true. 



mu = s 

^ , = l s = 

p ' ip |0 otherwise 

[4] = {S iip = F, 

p ' ip [S \[A] p>(p otherwise 
[Aq A Ai] P)V , = |A 0 ] p>(p n [Ai] Pjl p 
[Ao V Ai]p j( p = |A 0 ]p >( p U [Ai]p i¥ , 

I( a M]U = {p G S' | 3 q£ [A] P)V , ,p q A a’ => a A ->(p => ->«')} 

[(a)A] p>( p denotes the set of states p such that there exists a state of [A]p iV , 
reachable from p by the transition a! /a with a' => a. The condition p => -> a' 
allows to detect a contradiction between p and the transition condition a'; these 
conditions will be used to prune branches in the exploration tree. 



IHA]p,<p = {p £ S I Vg, {ip q A a' => a) => q G [A] p>¥ , ) A ->(<p => Ha')} 

|[a]A] p>( p denotes the set of states p such that for all state q, if q is reachable 
from p by the transition a' /a, with a! => a, then q belongs to the set |A] P>¥ , . 

[*W = p(X) 

lvX{r}A] Ptlp = U{E C S \ EC{n \ (n, Pi) G { 7 } A Equiv(p, p^} 

U Mp[E/X],y} 

where the equivalence between p and pi, Equiv{p, pi), can be roughly expressed 
as follows: the values of every variable v in p and p t must correspond to com- 
parable expressions (a matching function is used), and the condition parts of p 
and Pi (conjunctions of the a') must be equivalent in the state defined by the 
equalities induced by the assignments a of p and pi (after eliminating irrelevant 
terms i.e. , terms that involve identifiers that are no longer in use). 

Equiv(p, pi) = Matchjuariables(p, pi) A 

( Equalities(p ) A Equalities(pi) => (C onditions{p) <t=> Conditions(pi))) 
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Let us see how tp' (the condition associated with q in the semantics of <C> and 
□ ) is defined, tp' = Nexttpfp, a' , a, p) can be seen as a renaming of tp A a' A a : 
the property associated with q is the conjunction of the previous property tp with 
the condition a ' of the transition that is taken (excluding the conditions on the 
inputs, that become obsolete), and with the assignments a (interpreted as equal- 
ities) performed on this transition. We give the definition of Nexttp(tp,a! ,a,p) 
below, it will be illustrated on an example in Section 3.2. For each variable v, 
v 1 refers to its next value. In the very first step (i.e., tp = Pq A p = So), <p' 
corresponds to the conjunction Pq A a' A a (note that, for a uniform processing 
in the subsequent steps, each variable must be represented. Hence equalities of 
the form v' = v are introduced for every variable v that is not assigned in a). 
Afterwards, tp' is <p A a' , in which the assignments of a (where the inputs are 
indexed according to the step number) are incorporated. 

{ Po\i A a'\i A a' A f\ v' = v if first step 

veVnot assigned in a 

(Ti{tp, <72 (a, tp)) A <73(a'\i,(fi) otherwise 



where 

E\j is the expression E without the subexpressions that involve the inputs, 
a' is a where the assignments are interpreted as equalities and the left-hand side 
operands are primed, 

02 ( 0 , tp) = replace in a every input identifier i by ik (where k is the step number) 
and every assignment v = exp by the assignment v' = cr{exp, ip) 
where a(exp, tp) = replace in exp every v £ V by expi if the equality v' = 
exp\ is in tp, 

<j\(tp,A) = replace in tp every equality 1 / = exp± by the equality v' = exp 2 of 
A , and update the output values, 
a 3 {a,tp) =<r(a,tp). 



2.2 The Mo del- Checking Procedure 

Like [16], we define the semantics of correctness assertions, \p, tp h A]: 



Ip, P 1 - -41 



true if p e [-4] P , V 
false otherwise 



Example. Let us consider the system of Fig. 1. We can express for example the 
following invariant: when the output outc is true (the card can be retrieved), the 
number of attempts n is not greater than 3. 

Its formulation is 

S 0 , outc = false b vY {}{outc — true => n < 3) A [T]Y 

Thanks to the definition above and the ones of Section 2.1, we get the fol- 
lowing set of reduction rules. The model-checker algorithm (fixed-point compu- 
tation) corresponds to the application of these rules to rewrite the expression 
that corresponds to the property to be proven, until true or false is obtained. 




92 



Magali Contensin and Laurence Pierre 



( / ) (P, v y- f) 



{ true if <p => / 
false otherwise 
( T ) (p, ip h T) — » true 



(F) (p,ip\~F)- 
( ^ ) (p, P I" -’-4) 



true \i ip = F 
false otherwise 



true if ip — F 

[^ — >(j3, p h A) otherwise 
( A ) (p, ip \~ A 0 A Ax) -> (p, I- A 0 ) A (p, p h A ± ) 

( V ) 0, p A 0 V Ai) -> (p, h A 0 ) V (p, p h A{) 

(❖) (p, H (a)2l) -> Y (q,<p' FA) 

(g,a,a )£Reach pcx 

where Reach Pta = {(q, a, a) \ p q A a' => 

(□) (p,<p h [a] A) -> /\ (?,¥>' FA) 



a A -i(<p => ->c/)} 



(^) (p,<pl- uX{r}A) 



(g,a,a )€Reach PiOC 

j true if 3 (p, <pj) in { r } | Equiv(ip, tfi) 

\ (p, <p h A[j/A{ r , (p, <p)}A / X]) otherwise 



The theorem prover takes the relay when arithmetic properties have to be 
checked. These properties are: ip => / in the (/) rule, ip = F (= is the equiva- 
lence) in the (F) and (->) rules, a' => a and ->(<p => ->a') in the (<C>) and (□) 
rules, and Equiv{ip, ipi) in the (u) rule. We have chosen the ACL2 prover [18] that 
supports first order logic without quantifiers, integrates an induction mechanism 
to reason on inductively defined abstract data types, and imposes no restriction 
on arithmetic operators. Since the underlying logic is undecidable, the only case 
in which the algorithm cannot go on and requires user guidance is when the 
prover cannot decide whether a property is true. It is worth noticing that our 
methodology can be linked with other theorem provers, the choice of the prover 
(and of the associated logic) depends on the characteristics of the systems under 
consideration. In cases where a decidable framework (for instance Presburger 
arithmetic) suffices, processing the properties above can be fully automated. Let 
us also remark that the set of data types that can be handled is also a conse- 
quence of the choice of the prover. For instance, ACL2 is very powerful with 
integers, and also allows to reason with floating-point operators. 



3 Implementation of This Methodology 

3.1 The Prototype Tool 

We have implemented a prototype tool that can be used on a network of worsta- 
tions under any web browser, see a screen dump on Fig. 2. It takes as input 
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Fig. 2. Screen dump of an execution 



simple textual descriptions: the list of inputs, outputs and variables (with their 
types), followed by the transcription of the transition system (for each transi- 
tion, the source and destination states, the transition condition and actions). 
Since this first prototype has only been realized to show the feasibility of the 
approach, without any optimization, CPU times devoted to graph explorations 
are not worth being reported (only the ACL2 CPU times will be mentioned). 

Using the “draw” button, a graphical view of the automaton can be displayed 
in the left frame; graphical options can be chosen for drawing the picture. 

The designer also has the possibility to compute the parallel composition of 
several automata, which is useful when a complex specification is expressed as the 
composition of subsystems (e.g. different actors involved in a mutual exclusion 
algorithm, the sender and the receiver in a communication protocol, etc.). 

Before running formal verification tools, it can be useful to perform debugging 
steps by executing the specification. To achieve that goal, it is also possible to 
translate into a C program the original specification file. 

The main component of this tool is the model-checker described in the pre- 
vious section. The user has to supply the property p he wants to check, the 
initial state So, and the conjunction of properties Pq that hold in the initial 
state and that are relevant for processing p. The tool displays a human read- 
able and concise view of its execution, a debug mode can be chosen to get more 
detailed information. It writes the name of the rule that is being applied, and 
the property currently under consideration. Each time ACL2 is used, the tool 
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informs the user and displays the returning status (Q . E . D . in case of success and 
Failed if failure). A module should be included to allow user guidance when the 
prover cannot decide. This module, that has not yet been implemented, would 
allow a more elaborate dialogue between the user and the prover, and prevent 
the fixed-point algorithm from going on until a definitive answer is obtained. 

Example. Let us consider the 2-process version of the famous Bakery algorithm 
for mutual exclusion (see for instance [4]). 



shared variables yl,y2 initially 0; 



loop { 

NC section; 

2/1 <- 3/2 + 1 ; 

await j/2 = 0 V 2/1 < i/2 

CR section; 

2/1 0 ; 

} 

(a) Process 1 



loop { 

NC section; 

J/2 <— 2/1 + i; 

await 2/1 = 0 V 2/2 < 2/1 

CR section; 

J/2 <— 0; 

} 

(b) Process 2 




Fig. 3. 2-process Bakery algorithm 



Variables y± and 1/2 are used to determine which process can enter the critical 
section. Fig. 3(a) and 3(c) give the algorithm and the corresponding automaton 
for process 1: its starts its execution in state P1NC (non critical section), and 
can enter the critical section (state P1CR) only if the second process does not 
make a request (3/2 = 0) or if y 1 < 3/2- The second process has a symmetrical 
behaviour: it can enter the critical section only if the first process does not make 
a request (3/1 = 0) or if 3/2 < 3/1- 

Our tool can build the composition of the processes, as represented on Fig. 
4, and then model-check this specification. For instance, verifying that mutual 
exclusion is guaranteed requires the exploration of 11 states (the exploration path 
is highlighted with heavy lines on Fig. 4), there is only one case in which the (v) 
rule prevents from entering a loop (state P1LAP2L2) but the (□) rule allows 
to prune 8 branches (contradiction between the transition condition and the 
current property). ACL2 processes 25 non-trivial properties (a trivial theorem 
is for instance T 4=> T) in a total CPU time of 0.06 s on a Pentium 4. 
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Process 1: condition/action 
IT/- 

2 T / yi <— y 2 + 1 

3 -'(j /2 = 0 V yi < y 2 ) / - 
4b=0Vvi<b / - 

5 T / — 

6 T / i/i <- 0 



Process 2: condition/action 

1’ T / » 

2’ T / y 2 •>— 2/1 + 1 
3’ — '(yi =0 Vi/2<!/i)/- 
4’ yi = 0 V y 2 < 2/1 / - 
5’ T / — 

6’ T / i/2 <— 0 



Fig. 4. Parallel composition for the 2-process version of the Bakery algorithm 



3.2 Detailed Execution on an Example 

Considering the cash withdrawal system of Fig. 1, we now illustrate the algorithm 
with the following property (this is the one used in the screen dump of Fig. 2): 

S 0 ,P 0 ^vY{}<t>(Y) 

where <fi(Y) = (( outc = true => n < 3) A [T]F) and Pq is owtc = false. 

The algorithm executes as follows. The execution tree is given on Fig. 5, the 
leaves correspond to states in which the (v) rule detects that it is not necessary 
to go on (state already traversed with an equivalent condition). 

So, Pq h vY {}((outc = true => n < 3) A [T)Y) 

P —y Sq, Pq h ( outc = true => n < 3) A [T)isY{(So, Po)}4>(Y) 

So, Pq F ( outc = true => n < 3) A Sq, Pq F [T)uY{(So, Po)}<^(^) 

M true A So, P 0 F [T]uY{{S 0 , P 0 )}<j>(Y) 

The first part of the conjunction reduces to true as Pq includes outc = false. 
This corresponds to the elementary ACL2 theorem below (ACL2 uses a Lisp-like 
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syntax, each variable is implicitly universally quantified, nil is the counterpart 
of false). For the sake of simplicity, the other ACL2 theorems will not be given 
(none of them is difficult to prove, but some of them have long statements) . 

(defthm cashmachinel 

(implies (and (booleanp outc) ; outc is a boolean 

(integerp n) (>= n 0) ; n is a natural number 
(equal outc nil)) 

(implies (equal outc t) (<= n 3)))) 

The second part is rewritten with the (□) rule, two cases are considered: the 
loop to state So and the transition to S i. 

50, P 0 A ok' = ok A code' = code A n' = n b uY{(So, Po)}4>(Y) A 

51, Pi \-vY(So,P 0 )<KY) 

where P\ = (Po A ok' = ccq A code' = code An' = n). 

The property ip associated with So is obtained by the function N extip. The 
transition condition on the input inc refers to its value in the previous state 
and is obsolete, hence not included. There is no assignment performed on this 
transition, ok' = ok A code' = code A n' — n expresses that the variable values 
are not modified. Similarly, the property P 4 associated with Si includes ok' = 
cco A code' = code A n' = n to express that the only assignment realized on 
the corresponding transition is ok <— cc (this is the first time the input cc is 
consulted, it is numbered 0 ). 

true A Si,Pi b uY{(S 0 , Po)}<P(Y) 

the (n) rule detects that So has already been encountered with a caracteristic 
property equivalent to the current one, and it stops iterating on this branch. 

— Si, Pi b ( outc = true => n < 3) A [T]uY{(So, Po), (Si, Pi)}4>(Y) 

M true A Si, Pi b [T]uY{(S 0 , P 0 ), (S 1; Pi)}^) 

5 2 , P 2 b vY{(So, Po), (Si,Pi)}<f(Y) 



where P 2 = (Po A ok' = ccq A code' = codino An' = n + 1). 

— ■» S 2 ,P 2 b (outc = true => n < 3) 

A [T]vY{(So, Po), (Si, Pi), (S 2 , P 2 )}m 

true A S 2 ,P 2 b [T)uY{(S 0 , P 0 ), (Si, Pi), (S 2 ,P 2 )}^(Y) 

Si,P 3 b z/r{(S o ,Po),(Si,Pi),(S 2 ,P 2 )}0On A 

5 3 , P 4 b vY{(S 0 , Po), (S 1; Pi), (S 2 , Pi)}4>(Y) A 

5 4 , P 5 b vY{(So, Po), (Si, Pi), (S 2 , P 2 )}4>(Y) 

The (□) rule considers the three successor states Si, S 3 and S 4 of S 2 . In the 
first case, after going through Si with the property P 3 = (P 2 A -i( codino = 
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cco) A (n +1) < 3), we come back to S 2 with P§ = ( Pq A ok' = cco A code' = 
codini A n! = n + 2 A ->( codino = cco) A (n +1) < 3). Note that the function 
N extip updates the variable values, and replaces their names by their symbolic 
values in the transition conditions when they are integrated. 

5 2 , P 6 b [T]uY{(S 0 ,Po),(Si,Pi),(S2,P2),(Si,P3)mY) 

Si,Pt I- vY{{S 0 ,Po),{Si,Pi),{S2,P2),{Si,P 3 )}<KY) A 

53, Ps I- vY{(S 0 , Po), (Si, Pi), (S 2 , P 2 ), (Si, P 3 )}^(y) A 
s 4 , P9 1- ^{(s 0 , Po), (Si, Pi), (s 2 , P 2 ), (Si, p 3 )}0(y) 

- First, let us consider the transition to Si with P 7 = (Pq A ->( codini = cco) A 
(n + 2) < 3). The (v) rule detects that P 7 and P 3 are equivalent: both of them 
express that -<(code' = ofc') A n' < 3, and the variables code' and n' are of the 
same form in both of them (a non-constant atom and an additive expression 
respectively). The exploration stops on this branch. 

- In the third case, the transition to S 4 is associated with the property Pg = 
(Pq A codini = cco A (n + 2) < 3) . Then we reach the state S 5 with the property 
P 10 = (outc = true A ok' = cco A code' = codini A n' = n + 2 A -»( codino = 
cco) A (n + 1) < 3 A codini — ccq A (n + 2) < 3). 

S 5 , Pm b outc = true =>■ n < 3 A 

s 5 ,p 10 b[T]^y{(So,Po),(s 1 ,p 1 ),(s 2 ,p 2 ),(Si,p 3 ),(s 2 ,p 6 ),(S 4 ,p 9 )My) 

In the first part of this conjunction, the (/) rule applies. The hypothesis P 10 
indicates that outc = true and n! < 3, hence the (/) rule returns true because 
tp =$■ f (the variable identifiers are primed in / to coincide with the identifiers 
in ip). The second conjunct is rewritten with the (□) rule: 

S 6 , Pro I- [T]nY{(S 0 , P 0 ), (Si, Pi), (S 2 , P 2 ), (Si, P 3 ), (S 2 , P 6 ), (S 4 , Pg)}^) 

^S 5 , P 10 b ^F{(S 0 , Pq), (Si, Pi), (S 2 , P 2 ), (Si, P 3 ), (S 2 , P 6 ), (S 4 , Pg)}0(T) A 
So, Pn b i/b{(S 0 , P 0 ), (Si, Pi), (S 2 , P 2 ), (Si, P 3 ), (S 2 , P 6 ), (S 4 , Pg)}</>(F) 

The (v) rule straightforwardly reduces the first conjunct to true because the 
state S 5 with the property Plo as already been explored. 

In the case where we reach So, Pn is (outc = false A ok' = cco A code' = 
codini A n! = 0 A ->( codino = cco) A (n + 1) < 3 A codini = cco A (n + 2) < 3). 
The two possible next states are So and Si. The property associated with So 
is still Pn, thus the (n) rule decides to stop. Next state Si is associated with 
the property (outc = false A ok' = cci A code' = codini A n' = 0 A ->( codino = 
cco) A (n + 1) < 3 A codini = cco A (n +2) < 3), the variable ok has received 
a new input value cci. Eliminating the irrelevant hypotheses (hypotheses that 
concern identifiers that are no longer involved in the expressions assigned to the 
variables), this property is equivalent to Pi. Therefore, the ( v ) rule stops in this 
case too. 
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On the branch that corresponds to the successor (S 3 , P$) of (S 2 , Pe)> the algo- 
rithm stops for similar reasons. 

As for the successors ( S 3 ,P 4 ) and (S 4 . P- } ) of (S 2 , P 2 ), the algorithm has a be- 
havior that is close to what has been described above. Finally, true is returned, 
which means that the temporal property under consideration holds. 




s 0 s ! 



Fig. 5. Execution tree 



Fifteen states are actually explored, the (v) rule prevents from entering loops 
in 12 states (the leaves); 54 non-trivial properties are submitted to ACL2, for a 
total CPU time of 0.26 s. 

The (v) rule makes use of the function Equiv to recognize equivalent states 
and to stop the fixed-point iteration. If ip and (pi are characterized by equivalent 
conditions, but present different constant values for the corresponding variables, 
they cannot be considered equivalent. Our strategy is well-suited to general prob- 
lems that do not require variables to be given specific initial values. This is the 
case with this formulation of the cash machine, that specifies a correct behaviour, 
whatever the initial value of n is. 

4 Related Work 

4.1 Model-Checking/Theorem-Proving Combined Approaches 
with Reduction 

Most model-checking/theorem proving combined approaches try to reduce the 
size of the problem before solving it [19]. Some of them exploit the modular struc- 
ture of the system to decompose the initial problem into smaller sub-problems. 
Other ones build on abstraction techniques. 
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Using modularity, the proofs are broken down by exploiting the hierarchy of 
the system. Each finite module is independently checked by a model-checker. 
The role of the theorem provers is usually to verify that the composition of the 
verified modules entails the specification. Mocha [20] exploits the hierarchy of 
the design; it is an interactive environment for the specification, simulation and 
verification of concurrent systems. Most of the verification work is done by the 
built-in or external model-checker. In [21], McMillan introduces compositional 
verification and symmetry reduction in SMV in order to reduce the problem into 
a set of subgoals discharged by model-checking. 

Abstraction techniques reduce the verification of a property of a concrete 
infinite-state or large system to checking a related property over a finite abstract 
system. The abstract problem is verified by model-checking, deductive methods 
are used either to produce it or to verify its correctness. InVeSt [22] belongs to 
this category of tools, it uses the reduction of the invariance problem to a set of 
first-order formulas, and fixed-point calculation; it integrates the theorem prover 
PVS [23] with the model-checker SMV. The approach proposed in [24] uses 
ACL2 to reduce an infinite-state system through the computation of a quotient 
structure induced by a well-founded equivalence bisimulation (WEB) . The prover 
is mainly used to verify that the selected equivalence relation is a WEB. The 
system STeP [4] integrates both abstraction techniques and modularity. The 
abstractions are deductively justified and algorithmically model-checked. 



4.2 Model-Checking as Decision Procedure in a Theorem-Prover 

Another current trend is the integration of model-checking modules as decision 
procedures within a theorem prover. The authors of [25] integrate a /./-calculus 
model-checker as a decision procedure for a fragment of the PVS lriglrer-order 
logic corresponding to a finite //-calculus. Moreover, [26] gives a method to build 
predicate abstraction for the //-calculus; PVS is used to determine when predicate 
abstraction is needed. 

In [27] the linear temporal logic LTL is embedded in the theorem prover 
HOL. The translation of LTL formulas into equivalent w-automata permits the 
integration of ad hoc symbolic model-checkers as decision procedures in HOL. 

5 Conclusion 

We have presented a methodology in which a combination of algorithmic and 
deductive techniques allows to model-check unbounded systems without using 
state space reduction. A prototype tool has been developed, the role of this first 
prototype is not to measure the efficiency of the algorithm in terms of CPU 
times, but to demonstrate the feasibility and the interest of the approach. 

The technique can be applied to software specifications as well as to some 
kinds of high-level hardware descriptions. In section 3, we have mentioned its 
application to two software problems, a mutual exclusion algorithm and the 
controller of a cash withdrawal system. We are currently considering another 
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class of problems, the communication protocols, e.g. FDDI. Hardware devices 
made of a control part and a data part are also among the applications of the 
method presented here. For instance, this tool has also been used to reason on a 
high-level (behavioural) specification of a circuit that realizes a GCD function, 
we have proved a loop invariant that ensures the validity of the implementation. 
The arithmetic theorems involved in this benchmark are more complex than in 
the examples above. Twenty-one states are traversed by the algorithm, the {v) 
rule prevents from entering loops in 21 states, ACL2 processes 111 non-trivial 
properties in a total CPU time of 2.01 s. 

In the current prototype tool, the mechanism that applies the rewrite rules 
for the state space exploration has not been optimized. Moreover the tool does 
not give the user the possibility to interact with the prover. This tool is be- 
ing reimplemented, data structures and the associated functionalities will be 
improved, and a module for guiding the prover when necessary will be included. 
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Abstract. Formal certification is based on the idea that a mathemat- 
ical proof of some property of a piece of software can be regarded as a 
certificate of correctness which, in principle, can be subjected to exter- 
nal scrutiny. In practice, however, proofs themselves are unlikely to be of 
much interest to engineers. Nevertheless, it is possible to use the infor- 
mation obtained from a mathematical analysis of software to produce a 
detailed textual justification of correctness. In this paper, we describe an 
approach to generating textual explanations from automatically gener- 
ated proofs of program safety, where the proofs are of compliance with an 
explicit safety policy that can be varied. Key to this is tracing proof obli- 
gations back to the program, and we describe a tool which implements 
this to certify code auto-generated by AutoBayes and AutoFilter, pro- 
gram synthesis systems under development at the NASA Ames Research 
Center. Our approach is a step towards combining formal certification 
with traditional certification methods. 



1 Introduction 

Formal methods are becoming potentially more applicable due, in large part, 
to improvements in automation: in particular, in automated theorem proving. 
However, this increasing use of theorem provers in both software and hardware 
verification also presents a problem for the applicability of formal methods: how 
can such specialized tools be combined with traditional process-oriented devel- 
opment methods? 

The aim of formal certification is to prove that a piece of software is free 
of certain defects. Yet certification traditionally requires documentary evidence 
that the software development complies with some process (e.g., DO-178B). Al- 
though theorem provers typically generate a large amount of material in the form 
of formal mathematical proofs, this cannot be easily understood by people inex- 
perienced with the specialized formalism of the tool being used. Consequently, 
the massive amounts of material that experts can create with these theorem 
provers remains fairly inaccessible. If you trust a theorem prover, then a proof 

* Ram Prasad Venkatesan carried out this work during a QSS summer internship at 
the NASA Ames Research Center. 
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of correctness tells that a program is safe, but this is not much help if you want 
to understand why. 

One approach is to verbalize high-level proofs produced by a theorem prover. 
Most of the previous work in this direction has focused on translating low-level 
formal languages based on natural deduction style formal proofs. A few theorem 
provers, like Nuprl [CAB+86] and Coq [BBC + 97], can display formal proofs in 
a natural language format, although even these readable texts can be difficult 
to understand. However, the basic problem is that such proofs of correctness 
are essentially stand-alone artifacts with no clear relation to the program being 
verified. 

In this paper, we describe a framework for generating comprehensive expla- 
nations for why a program is safe. Safety is defined in terms of compliance with 
an explicitly given safety policy. Our framework is generic in the sense that we 
can instantiate the system with a range of different safety policies, and can easily 
add new policies to the system. 

The safety explanations are generated from the proof obligations produced 
by a verification condition generator (VCG). The verification condition gener- 
ator takes as input a synthesized program with logical annotations and pro- 
duces a series of verification conditions. These conditions are preprocessed by a 
rewrite-basecl simplifier and are then proved by an automated theorem prover. 
Unfortunately, any attempt to directly verbalize the proof steps of the theorem 
prover would be ineffective as 

— the process of simplifying the proof objects makes it difficult to provide a 
faithful reproduction of the entire proof; 

— it is difficult to relate the simplified proof obligations to the corresponding 
parts of the program. 

We claim that it is unnecessary to display actual proof steps - the proof 
obligations alone provide sufficient insight into the safety of a program. Hence 
we adopt an approach that generates explanations directly from the verification 
conditions. Our goals in this paper are: 

— using natural language as a basis for safety reports; 

— describing a framework in which proofs of safety explicitly refer back to 
program components; 

— providing an approach to merge automated certification with traditional 
certification procedures. 

Related Work. Most of the previous work on proof documentation has focused 
on translating low-level formal proofs, in particular those given in natural de- 
duction style. In [CKT95], the authors present an approach that uses a proof 
assistant to construct proof objects and then generate explanations in pseudo- 
natural language from these proof objects. However, this approach is based on 
a low-level proof even when a corresponding high-level proof was available. The 
Proverb system [Hua94] renders machine-found natural deduction proofs in nat- 
ural language using a reconstructive approach. It first defines an intermediate 
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representation called assertion level inference rules, then abstracts the machine- 
found natural deduction proofs using these rules; these abstracted proofs are 
then verbalized into natural language. Such an approach allows atomic justifica- 
tions at a higher level of abstraction. In [HMBC99], the authors propose a new 
approach to text generation from formal proofs exploiting the high-level inter- 
active features of a tactic-style theorem prover. It is argued that tactic steps 
correspond approximately to human inference steps. None of these techniques, 
though, is directly concerned with program verification. Recently, there has also 
been research on providing formal traceability between specifications and gener- 
ated code. [BRLP98] presents a tool that indicates how statements in synthesized 
code relate to the initial problem specification and domain theory. In [WBS + 01], 
the authors build on this to present a documentation generator and XML-based 
browser interface that generates an explanation for every executable statement 
in the synthesized program. It takes augmented proof structures and abstracts 
them to provide explanations of how the program has been synthesized from a 
specification. 

One tool which does combine verification and documentation is the PolySpace 
static analysis tool [Pol] . PolySpace analyzes programs for compliance with fixed 
notions of safety, and produces a marked-up browsable program together with a 
safety report as an Excel spreadsheet. 

2 Certification Architecture 

The certification tool is built on top of two program synthesis systems. Auto- 
Bayes [FS03] and AutoFilter [WS03] are able to auto-generate executable code 
in the domains of data analysis and state estimation, respectively. Both systems 
are able to generate substantial complex programs which would be difficult and 
time-consuming to develop manually. Since these programs can be used in safety- 
critical environments, we need to have some guarantee of correctness. However, 
due to the complex and dynamic nature of the synthesis tools, we have departed 
from the traditional idea of program synthesis as being “correct by construction” 
or process- oriented certification, and instead adopt a product- oriented approach. 
In other words, we certify the individual programs which are generated by the 
system, rather than the system itself. 

The synthesis tools, themselves, are about 75KLOC, use many “non-trivial” 
features of Prolog, and are continually being extended by a number of developers. 
Requiring ongoing verification of the system itself would cripple development. 
The programs generated, on the other hand, are in a “clean” imperative subset 
and so it is substantially easier to extend the systems to enable certification of 
the programs they generate. 

Figure 1 gives an overview of the components of the system. The synthesis 
system takes as input a high-level specification together with a safety policy. Low- 
level code is then synthesized to implement the specification. The synthesizer 
first generates “intermediate” code which can then be translated to different 
platforms. A number of target language backends are currently supported. The 
safety policy is used to annotate the intermediate code with mark-up information 
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relevant to the policy. These annotations give “local” information, which must 
then be propagated throughout the code. Next, the annotated code is processed 
by a Verification Condition Generator (VCG), which applies the rules of the 
safety policy to the annotated code in order to generate safety conditions (which 
express whether the code is safe or not). The VCG has been designed to be 
“correct-by-inspection”, that is, sufficiently simple that it is relatively easy to be 
assured that it correctly implements the rules of the safety logic. In particular, 
the VCG does not carry out any optimizations, not even reducing substitution 
terms. Consequently, the verification conditions (VCs) tend to be large and must 
be preprocessed before being sent to a theorem prover. The preprocessing is done 
by a traceable rewrite system. The more manageable SVCs are then sent to a 
first-order theorem prover, and the resulting proof is sent to a proof checker. In 
the above diagram, the safety documentation extension is indicated using dotted 
lines. 



3 Safety Policies 

Formal reasoning techniques can be used to show that programs satisfy certain 
safety policies , for example, memory safety (i.e. they do not access out of bound 
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memory locations), and initialization safety (i.e. undefined or uninitialized vari- 
ables are not used) . Formally, a safety policy is a set of proof rules and auxiliary 
definitions which are designed to show that programs satisfy a safety property of 
interest. The intention is that a safety policy enforces a particular safety prop- 
erty, which is an operational characterization that a program does not go wrong. 
The distinction between safety properties and policies is explored in detail in 
[DF03]. We summarize the important points here. 

Axiomatic semantics for (simple) programming languages are traditionally 
given using Hoare logic [Mit96], where P {C} Q means that if precondition, 
P, holds before the execution of command, C, then postcondition, Q, holds 
afterwards. This can be read backwards to compute the weakest precondition 
which must hold to satisfy a given postcondition. 

We have extended the standard Hoare framework with the notion of safety 
properties. [DF03] outlines criteria when a (semantic) safety property can be 
encoded as an executable safety policy. 

We have initially restricted ourselves to safety of array accesses (ensuring 
that the access is within the array bounds) and safety of variables with respect 
to initialization (ensuring that all variables which are read have been assigned 
to). However, the tool has been designed to be generic and we intend to extend 
it to support other forms of safety. 

Hoare logic treats commands as transformations of the execution environ- 
ment. The key step in formalizing safety policies is to extend this with a 
“shadow”, or safety environment. Each variable (both scalar and vector) has 
a corresponding shadow variable which records the appropriate safety informa- 
tion for that variable. For example, for initialization safety, the shadow variable 
;r init is set to init. or uninit depending on whether x has been initialized or not. In 
general, there is no connection between the values of a variable and its shadow 
variables. The semantic definition of a safety property can then be factored into 
two families of formulas, Safe" and Sub~(_). A feature of our framework is that 
the safety of a command can only be expressed in terms of its immediate subex- 
pressions. The subscripts give the class of command (assignment, for-loop, etc.), 
and the superscript lists the immediate subexpressions. 

For a given safety policy, for each command, C, of class cl with immediate 
subexpressions, e\ . . . e n , Safe^'" 6 ” expresses the safety conditions on C, in terms 
of program variables and shadow variables; Sub^ ' 6 ” (P) is a substitution applied 
to formula P expressing the change C makes to the safety environment. 

For example, for the initialization safety policy, the assignment x := y has 
safety condition, Safe^sign, which is the formula y init = init (i.e., a y must be 
initialized”) and, for formula P, Sub:(W gn (P) is the safety substitution P[init/x\ 
(i.e., “x becomes initialized”). 

Hence, in our framework, verifying the safety of a program amounts to work- 
ing backwards through the code, applying safety substitutions to compute the 
safety environment, and accumulating safety obligations while proving that the 
safety environment at each point implies the corresponding safety obligations. 
Explaining the safety of a program amounts to giving a textual account of why 
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(decl) 

(adecl) 

(assign) 

(update) 

(if) 



lab(/, SubJ ecl (Q) A SafeJed) {(var x)'} Q 

lab(/,Sub^™ cl (Q) ASafe^) {(varrW) 1 } Q 

lab(/,Sub:-: ign (Q)ASafe- s e ign ) {(x := e)*} Q 

lab(i, Sub^; 2 (Q) A Safe™* ) {(x [ei] : = e 2 )*} Q 
Pi {ci } Q P2 {02} Q 

lab(if (Z), Subi f (6 => Pi A ->b => P 2 ) A Safe^ ) {(if Zrthenci else C2) 1 } Q 



(while) 



P {c} I I&zb=>P I&z^b => Q 

lab(wh(?), inv(7), Sub^ hile (7) A Safe^ hila ) {(while b inv 7 do c) 1 } Q 



(comp) 



P {ci} R R {c 2 } Q 
P {ci;c 2 } Q 



Fig. 2. Extended Hoare Rules 

these implications hold, in terms relating to the safety conditions and safety 
substitutions. 

Our goal, then, is to augment the certification system such that the proof 
obligations have sufficient information that we can give them a comprehensible 
textual rendering. We do this by extending the intermediate code to accommo- 
date labels and the VCG to generate verification conditions with labels. We add 
labels for each declaration, assignment, loop construct and conditional statement 
by giving them a number in increasing order starting from zero. For loops and 
conditions, we also add the command type to the label. For example, for loops 
are given a label for (label). Similarly, we also have labels if (label) and wh [label). 
Figure 2 gives the Hoare rules extended by labels which are implemented by the 
VCG. The composition rule is the standard one. The conclusions of the other 
rules, which have the general form lab(P,P) {c z } Q , when read backwards, say 
that in order to satisfy the postcondition, Q, the command, c, labeled by l, re- 
quires precondition, P, which is given label, L (i.e. the command label, l, and 
possibly the command type). In the rule for while loops, P denotes P with labels 
removed. 

4 Documentation Architecture 

In this section, we introduce the general architecture of the safety document 
generator and discuss the notions of def-use analysis and template composition. 

4.1 Document Generator 

Figure 3 shows the structure of the document generation subsystem. The syn- 
thesized intermediate code is labeled by adding line numbers to the code before 
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Fig. 3. Document Generation Architecture 

it is sent to the VCG. The VCG then produces verification conditions for the 
corresponding safety policy. These verification conditions preserve the labels by 
encapsulating them along with the weakest safety preconditions. 

Because of the way our safety logic is formulated in terms of immediate 
subexpressions of commands, we define a fragment to be a command “sliced” 
to its immediate subexpressions. For atomic commands, this is equivalent to the 
command itself. For compound commands, we will represent this as if 6 and 
while 6. These are the parts of a program that require an independent safety 
explanation. 

The document generator takes as input the verification conditions gener- 
ated in this manner and first identifies each fragment that requires explanation 
(for array safety, any fragments which contain array accesses and for initializa- 
tion safety, any fragments containing variable reads) . It then selects appropriate 
explanation templates from a repository of safety-dependent templates. Text is 
then generated by instantiating the templates with program fragments and com- 
posing the results. 

4.2 Def-use Analysis 

Since commands can affect the safety of other commands in their effect on the 
program environment we cannot consider the safety of commands in isolation. 
In particular, the safety of a command involving a variable x depends on the 
safety of all previous commands in the program that contain an occurrence of 
x. Consider the following code: 
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(LI) x = 2 ; 

(L2) y = x ; 

(L3) a[y] =0 ; 

Now consider the safety of the expression a[y] = 0 with respect to array 
bounds. To determine whether this access is safe, we need to ensure that the 
value held by y is within the array bounds. Now supposing that a is an array of 
size 10, we need to reason that y is defined from x which in turn is initialized to 
2, which is less than 10. Hence we can state that the access is safe. Similarly, if we 
were analyzing the safety of the same expression with respect to initialization, we 
would need to convince ourselves simply that y is initialized. Reasoning from y = 
x alone would be insufficient and incorrect because x could be uninitialized. So we 
need to convince ourselves that x is also initialized by considering the expression 
x = 2. In other words, the safety of the expression a[y] =0 depends on the 
safety of the fragments y=x and x=2. 

To summarize, we trace each variable in a program fragment <fi to the point 
where it was first defined or initialized and reason about the safety of all the 
fragments encountered in the path to obtain a thorough explanation of the safety 
of <j). For a given program fragment (j) having variables w, we use 17 (</>) to represent 
the set of all fragments, with their labels, that were encountered while tracking 
each variable in uj to its origin. We also include <fi in 17 (</>). Strictly speaking, 
the argument to 17 should be a distinguished occurrence of a fragment within a 
program, but we will gloss over this. 

4.3 Contexts 

In addition to tracking variables to their original definition, we also need to 
find which fragments the fragment under consideration depends on. For exam- 
ple, the safety of an assignment statement appearing within a conditional block 
also depends on the safety of the conditional expression. Similarly, the safety of 
statements inside while loops depends on the safety of the loop condition. In 
the case of nested loops and conditional statements, a fragment’s safety depends 
on multiple fragments. To provide complete safety explanations for a program 
fragment , we construct a set 1 S' sp ( </>) as follows. As above, (j> is assumed to be 
distinguished within a given program. We first identify all the fragments (j)' on 
which 4> depends. That is, if lies within conditional blocks and/or loop blocks, 
then we include the fragments representing those conditional expressions and/or 
loop expressions in (j)' . We will refer to this as the context of the fragment, <f>, 
and denote it by ext ((/>). Since we add special labels to loops and conditional 
statements, we can easily identify blocks and can easily determine the set cf>' . 

1 In the implementation, this is a tree. 
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Then, we trace each component and variable in the fragment <f> and the set of 
fragments </>' to their origin (as explained in the previous section); that is, 

T sp (4 >) = u I <f> e ext (</))}. 

Intuitively, we can view I/ sp ((j)) as the set of all expressions and program 
fragments that we need to consider while reasoning about the safety of (j> with 
respect to the safety policy sp. Each element in this set is represented as a (label, 
fragment ) pair. 

We now state (without proof) that 4> is safe if each of the fragments in \P sp ((j>) 
is safe. That is, 

sa f e S p(^ r sp(4 > )) => safe sp ((j>). 

Here, we use the predicate safe to indicate that a set of program fragments are 
safe with respect to a policy sp. 

For example, consider the following piece of code in C: 

(1) x = 5 ; 

(2) z = 10 ; 

(3) if(x > z) 

(4) y = x ; 
else 

(5) y = z ; 

The safety of the assignment y = x at line 4 with respect to initialization of 
variables depends not only on the assignment statement y = x but also on the 
the conditional fragment if (x > z) so, in this case, for the program fragment 
y = x, the context would be simply {if (x > z)}. We can further deduce that 
the safety of the conditional statement in turn depends on the two assignment 
statements x = 5 and z = 10. So, to explain the safety of the expression y = 
x at line 4, we need to reason about the safety of the fragments if (x > z) , 
z = 10 and x = 5 at lines 3, 2 and 1 respectively. Hence, 'T sp (y = x) is the set 
{(4,y = x), (3, if (x > z)), (2, z = 10), (1, (x = 5))}. 

4.4 Templates 

We have defined a library of templates which are explanation fragments for the 
different safety policies. These templates are simply strings with holes which can 
be instantiated by program components to form safety explanations. A program 
component can be a simple program variable, a program fragment, an expression 
or a label. 

Template Composition and Instantiation: The composition of an explanation 
for a given program fragment is obtained from the templates defined for a given 
policy, sp. For each fragment, <f>, we first construct the set T sp (cj)). Then, for 
each element %/) in W sp (4>), we find the required template(s), Temp sp (il >) . Next we 
insert the appropriate program components in the gaps present in the template 
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to form the textual safety explanation. This process is repeated recursively for 
each fragment in and then all the explanations obtained in this way are 

concatenated to form the final safety explanation. It should be noted that the 
safety explanations generated for most of these fragments are phrases rather 
than complete sentences. These phrases are then combined in such a manner 
that the final safety explanations reflects the data flow of the program. 

As an example, consider the following code fragment: 

(1) var a[10] ; 

(2) x = 0 ; 

(3) a [x] =0 ; 

Here, a is declared to be an array of size 10 at line 1. x is initialized to 0 at line 
2 and a[x] is initialized to 0 at line 3. 

Considering the safety of the expression a[x] =0 ((/>), the set 'f' sp (0) is { (3, 
(a[x] =0)), (2, (x = 0))}. Now, for each of these program fragments, we 
apply the appropriate templates for array bounds safety and generate explana- 
tions by combining them with the program variables a and x along with their 
labels. In this case, the safety explanation is: 

The access a [x] at line 3 is safe as the term x is evaluated from x = 0 at 
line 2; x is within 0 and 9; and hence the access is within the hounds of the array 
declared at line 1. 

Now if we were interested in initialization of variables, the set is still 

{(3, (a[x] =0)), (2, (x = 0) )}. However, the template definitions for the 
same fragments differ and the explanation is: 

The assignment a[x] = 0 at line 3 is safe; the term x is initialized from x=0 
at line 2. 

5 Implementation and Illustration 

We now describe an implementation of the safety document generator based on 
the principles discussed in the previous sections and give an example of how it 
works for different safety policies. 

5.1 Implementation 

The process of generating the explanations from the intermediate language can 
be broadly classified into two phases. 

— Labeling the intermediate code and generating verification conditions. 

— Scanning the verification conditions and generating explanations. 

We scan the verification conditions to identify the different parts of the pro- 
gram that require safety explanations collecting as much information as possible 
about the different data and variables along the way, and computing the \P sp (<l>). 
Fragments that require safety explanations differ for different safety policies. 
Since we analyze the verification conditions and not the program, the safety 
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policy has already determined this. For example, for safety with respect to array 
bounds, the fragments that require explanations would be the array accesses 
in the program. On the other hand, we need to consider all variable assign- 
ments, array accesses and assignments, declarations, and conditional statements 
for safety with respect to initialization of variables. That is, we consider all frag- 
ments where a variable is used and determine whether the variable has been 
initialized. In addition, we also accumulate information about the program vari- 
ables, constants and the blocks. 

Finally, using the information that we have accumulated during the scan- 
ning phase, we generate explanations for why the program is safe. As we have 
already mentioned, our tool is designed to be generic. Irrespective of the safety 
policy that we are currently concerned with, the tool analyzes each fragment 
that requires an explanation, and generates explanations using templates as dis- 
cussed in the previous section. This approach makes extensions very easy as the 
introduction of a new safety policy only involves providing definitions of each 
template for the policy. 

5.2 A Simple Example 

We now give a (slightly contrived) example of some intermediate code and the 
corresponding explanations provided by the document generator. The program 
needs an invariant (not given here) in order to prove its safety for each policy. 
Our prototype will simply indicate where invariants have been used to prove a 
verification obligation. 



0 


proc (eg) 


{ 


1 


a [10] : int ; 


2 


b : int ; 


3 


c : int ; 


4 


d : int ; 


5 


x : int ; 


6 


b = 1 ; 


7 


c = 2 ; 


8 


d = b*b + c*c ; 


9 


f or (i=0 ; i<10 ; i++) 


{ 


10 


if(i < 5) 


11 


a[d+i] = i ; 
else 



12 a[2*d-l-i] = i ; 
> 

13 x = a [a [5]] ; 

> 
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The explanations generated for safety with respect to array bounds and ini- 
tialization are given in Figures 4 and 5, respectively. The explanations are only 
generated if the theorem prover successfully proves all the corresponding verifi- 
cation conditions, and this is noted at the end. Note that we currently perform 
no symbolic evaluation during the analysis. The safety of the final assignment is 
proven using the invariant. 



Safety Explanations for Array Bounds 

The access a[d+i] at line 11 (if the condition i<5 at line 10 is true) is safe as the term 
d is evaluated from d=b*b+c*c at line 8; the term b is evaluated from b=l at line 6; the 
term c is evaluated from c=2 at line 7; for each value of the loop index i from 0 to 9 
at line 9, d+i is within 0 and 9; and hence the access is within the bounds of the array 
declared at line 1. 

The access a[2*d-l-i] at line 12 (if the condition i<5 at line 10 is false) is safe as the 
term d is evaluated from d=b*b+c*c at line 8/ the term b is evaluated from b=l at line 
6; the term c is evaluated from c=2 at line 7; for each value of the loop index i from 0 
to 9 at line 9, 2*d-l-i is within 0 and 9; and hence the access is within the bounds of 
the array declared at line 1. 

The access a [a [5]] at line 13 is safe; using the invariant for the loop at line 9 and 
the postcondition i=9+l after the loop; a [5] is within 0 and 9; and hence the access is 
within the bounds of the array declared at line 1. 

[Certified by e-setheo on Mon Mar 15 17:58:28 PST 2004 for array policy.] 

Fig. 4. Auto-generated Explanation: array safety policy 



Safety Explanations for Initialization of Variables 

The assignment b=l at line 6 is safe. 

The assignment c=2 at line 7 is safe. 

The assignment d=b*b+c*c at line 8 is safe; the term b is initialized from b=l at line 
6; the term c is initialized from c=2 at line 7. 

The loop index i ranges from 0 to 9 and is initialized at line 9. 

The conditional expression i<5 appears at line 10; the loop index i ranges from 0 to 9 
and is initialized at line 9. 

The assignment a[d+i]=i at line 11 is safe (if the condition i<5 at line 10 is true); 
the term d is initialized from d=b*b+c*c at line 8; the term b is initialized from b=l at 

line 6; the term c is initialized from c=2 at line 7; the loop index i ranges from 0 to 9 

and is initialized at line 9. 

The assignment a[2*d-l-i]=i at line 12 is safe (if the condition i<5 at line 10 is 
false); the term d is initialized from d=b*b+c*c at line 8/ the term b is initialized from 

b=l at line 6; the term c is initialized from c=2 at line 7; the loop index i ranges from 

0 to 9 and is initialized at line 9. 

The assignment x = a [a [5]] at line 13 is safe; using the invariant for the loop at line 
9 and the postcondition i=9+l after the loop. 

[Certified by e-setheo on Mon Mar 15 18:02:24 PST 2004 for init policy.] 



Fig. 5. Auto-generated Explanation: init safety policy 
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6 Design Issues 

In this section, we present some issues that were analyzed during the design and 
implementation of the safety document generator and then describe features that 
we have implemented for flexibility. 

6.1 Invariants 

To enable the document generator to recognize those parts of the verification 
conditions which come from loop invariants, we need to specifically label them 
with labels of the form in v(/). Then, while generating explanations for fragments 
within loops, we first find if the loop has an explicit invariant. If it does, we check 
if the fragment shares any variables with the invariant. The idea behind this is 
that it is always possible that the loop invariant might be completely unrelated to 
the safety of a fragment within that loop. In such a case, our explanations should 
not consider the loop invariant. However, if the invariant does (presumably) 
affect the safety of a fragment, we incorporate it into the explanation using the 
label giving the line at which the invariant was defined. 

6.2 Simplifying the Explanations 

We have designed the document generator to be comprehensive. For some of the 
more complex programs synthesized by AutoBayes, the safety document can run 
to over a hundred pages. 

One technique which we have implemented is to allow users to slice the 
explanation with respect to specific variables or line numbers. The document 
generator will then provide explanations only for those fragments that fall within 
the parts of interest (as well as any fragments they depend on) . 

However, although slicing can be used to focus attention to individual areas, it 
is still nice to get an overall justification of why a program is safe. One important 
technique for making the tool scalable (discussed in the conclusion) is to make 
use of high-level structuring information from a model. Another is to observe 
that some facts are clearly more important than others. We have implemented 
a simple heuristic which ranks the fragments and displays them based on user 
request. For instance, initialization of variables to constants can be viewed as a 
trivial command so the corresponding explanation can be eliminated. We have 
categorized fragments (in order of increasing priority) in terms of assignments 
to numeric constants, loop variable initializations, variable initializations, array 
accesses and - the highest priority - any command involving invariants. 

The rationale behind giving explanations involving invariants the highest 
priority is that invariants are generally used to fill in the trickiest parts of a 
proof, so are most likely to be of interest. 

7 Conclusions and Future Work 

The documentation generation system which we have described here builds on 
our state-of-the-art program synthesis system, and offers a novel combination 
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of synthesis, verification and documentation. We believe that documentation 
capabilities such as this are essential for formal techniques to gain acceptance. 

Although we do not (yet) use any symbolical evaluation, we believe that the 
simple technique of analyzing the verification conditions provides useful insights. 
Our plan is to combine the safety documentation with ongoing work on design 
documentation. We currently have a system which is able to document the syn- 
thesized code (explaining the specification, how it relates to the generated code, 
design choices made during synthesis, and so on), either as in-line comments in 
the code or as a browsable document, but it remains to integrate this with the 
safety document generator. We intend to let the user choose between various 
standard formats for the documentation (such as those mandated by DO-178B 
or internal NASA requirements). 

A big problem for NASA is the recertification of modified code. In fact, this 
can be a limiting factor in deciding whether a code change is feasible or not. For 
synthesis, the problem is that there is currently no easy way to combine manual 
modifications to synthesized code with later runs of the synthesis system. We 
would like to be able to generate documentation which is specific to the changes 
which have been made. 

Finally, we intend to extend our certification system with new policies (in- 
cluding resource usage, unit safety, and constraints on the implementation en- 
vironment). The two safety policies which we have illustrated this with here 
are language-specific in the sense that the notion of safety is at the level of 
individual commands in the language. We have also looked at domain-specific 
policies (such as for various matrix properties) where the reasoning takes place 
at the level of code blocks. This will entail an interesting extension to the doc- 
ument generator, making use of domain-specific concepts, and we are currently 
redesigning our entire synthesis framework to make use of explicit domain mod- 
els. Clearly, reflecting the high-level structure of the code in the documentation 
will be important in making this approach scalable. 
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Abstract. Since Z, being a state-based language, describes a system in 
terms of its state and potential state changes, it is natural to want to 
describe properties of a specified system also in terms of its state. One 
means of doing this is to use Linear Temporal Logic (LTL) in which 
properties about the state of a system over time can be captured. This, 
however, raises the question of whether these properties are preserved 
under refinement. Refinement is observation preserving and the state of 
a specified system is regarded as internal and, hence, non-observable. 

In this paper, we investigate this issue by addressing the following ques- 
tions. Given that a Z specification A is refined by a Z specification C , 
and that P is a temporal logic property which holds for A, what tem- 
poral logic property Q can we deduce holds for C? Furthermore, under 
what circumstances does the property Q preserve the intended meaning 
of the property P? The paper answers these questions for LTL, but the 
approach could also be applied to other temporal logics over states such 
as CTL and the /it-calculus. 

Keywords: Z, refinement, temporal logic, LTL. 



1 Introduction 

Z [14], like other state-based languages such as B [1] and VDM [9], describes a 
system in terms of its state and the changes on this state. A specification typically 
comprises a state schema declaring and restricting a set of state variables, an 
initial state schema restricting the initial values of the state variables, and a 
set of operation schemas detailing possible changes to the state variables with 
respect to additional variables representing inputs and outputs. 

While invariant properties of the system can be captured directly by the 
specification, more complex behavioural properties need to be proved to hold. 
Given the emphasis on the state while specifying using Z, it seems natural to 
want to also describe desired behavioural properties in terms of the system’s 
state. Ideal for this purpose are temporal logics which define predicates over 
infinite sequences of states. They can be used to specify how the state of the 
system evolves over time, in a way that isn’t possible directly in the model. 

Along with their ability to capture behavioural properties in terms of state, 
temporal logics are also commonly used for describing properties in model check- 
ing [4]. Hence, investigating their use with Z is an important first step toward 
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developing model checking support for the language [13]. The most common 
temporal logics used in model checking are Linear Temporal Logic (LTL) [8], 
Computation Tree Logic (CTL) [8] and the ^-calculus [10]. In this paper, we 
focus on the use of LTL, although the approach we develop could also be used 
to similarly investigate CTL and the //-calculus. 

The purpose of the definition of refinement in Z is to formalise the develop- 
ment from an abstract to a more concrete specification [6] . It is therefore prudent 
to ask whether temporal logic properties are preserved under refinement. That 
is, if a property is proved to hold for a Z specification, will it also hold for a 
refinement of that specification? This question is complicated by the fact that 
refinement is defined to preserve observable properties. In Z, only the operations 
and their inputs and outputs are regarded as observable; the state of a specifica- 
tion, to which temporal logic properties refer, is regarded as internal and, hence, 
non-observable . 

In this paper, we develop a general approach for investigating preservation of 
temporal logic properties under refinement, and apply it to LTL. In Section 2, we 
provide an overview of refinement in Z and motivate our work with an indicative 
example of where a temporal property is not preserved. Our general approach 
to determining temporal logic property preservation is defined in Section 3 and 
applied to LTL in Section 4. We conclude with a discussion of related work and 
future directions in Section 5. 



2 Refinement 

Refinement in Z is defined so that the observable behaviour of a Z specification 
is preserved. This behaviour is in terms of the operations that are performed 
and their input and output values. Values of the state variables are regarded 
as being internal. Hence, they are not observable and properties on them are, 
in general, not preserved. The reason for regarding them as internal is so that 
refinement can be used to change the representation of the state of a system. 
This is referred to as data refinement. 

The definition of refinement in Z is derived from a relational model into which 
Z is embedded. The details of this are contained in [6], and if a specification C 
is a refinement of another specification A we write A C C . 

To prove a data refinement one needs to link the states in the abstract and 
concrete specifications via a relation known as the retrieve relation. The retrieve 
relation shows how a state in one specification is represented in the other. For re- 
finement to be complete, a relation, rather than simply a function, is required [6]. 

Given such a retrieve relation, simulation rules relating the schemas of the 
specifications are used to verify the refinement. The standard simulation rules 
for Z assume that operations have preconditions outside of which they can occur 
changing the state arbitrarily. Such arbitrary state changes make it difficult to 
prove any interesting temporal properties however. Hence in our approach, we 
adopt an alternative view of operations in which they are blocked, i.e., cannot 
occur outside their preconditions. 
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As well as facilitating the use of temporal logics, the blocking model also 
makes our approach applicable to variants of Z which adopt this model, such 
as Object- Z [12]. It is also equivalent to the standard non-blocking model of Z 
when operation preconditions are totalised, i.e. , post-states are defined for all 
pre-states. Such totalisation of preconditions would be necessary in standard Z 
for the specification to exhibit interesting temporal properties. 

As for standard Z refinement, there are two simulation rules for refinement 
under the blocking model which are together complete, i.e., all possible refine- 
ments can be proved with a combination of the rules (in fact, every refinement 
can be verified with one downward together with one upward simulation). 

The first rule, referred to as downward simulation, requires that 

1. the initial states of the concrete specification are related to abstract initial 
states, 

2. the concrete operations are only enabled in states related to abstract states 
where the corresponding abstract operations are enabled, and vice versa (i.e., 
they have equivalent preconditions), and 

3. whenever a concrete operation can result in the state change (t, t'), for any 
abstract state s related to t, the corresponding abstract operation can result 
in (s, s') such that s’ is related to t' . That is, the effect of the concrete 
operation is consistent with the requirements of the corresponding abstract 
operation. 

It is defined as follows [6]. (Note that the state variables of a schema S after 
each operation are denoted by S', and, in general, the Z notation is also used 
for expressing its own metatheory, details of this notation can be found in [6].) 

Definition 1. A Z specification with state schema CState, initial state schema 
CInit and operations COpi . . . COp n is a downward simulation of a Z speci- 
fication with state schema AState, initial state schema Alnit and operations 
AOpi . . . AOp n , if there is a retrieve relation R such that the following hold for 
all i : l..n. 

1. V CState • CInit => 3 AState • Alnit A R 

2. V AState; CState • R => ( preAOpi <t=> pre COpi) 

3. V AState ; CState; CState' • R A COpi =>■ (3 AState ' • R' A AOpi) 

The second rule, referred to as upward simulation, requires that 

1. there is an abstract state related to every concrete state, 

2. the initial states of the concrete specification are only related to abstract 
initial states, 

3. for every concrete state, there exists an abstract state, such that all opera- 
tions enabled on the abstract state are also enabled on the concrete state, 
and 

4. whenever a concrete operation can result in the state change ( t , t'), for any 
abstract state s' related to t', the corresponding abstract operation can result 
in (s, s') where s is related to t. 

It is defined as follows [6] . 
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Definition 2 . A Z specification with state schema CState, initial state schema 
CInit and operations COp\ . . . COp n is an upward simulation of a Z speci- 
fication with state schema AState, initial state schema Alnit and operations 
AOpi . . . AOp n , if there is a retrieve relation R such that the following hold. 

1. V CState • 3 AState • R 

2. V AState-, CState • CInit A R =$■ Alnit. 

3. V CState • 3 AState • V i : 1 ..n • R A ( preAOpi =t- pre COpf) 

4. Vi : l..n *V AState'-, CState-, CState' 

• ( COpi A R' =» (3 AState • R A AOpi) 

Note that we use a slightly stronger form of upward simulation, in particular, 
one where the quantification over the operations (that is, i) in condition 3 is 
after the existential quantification of the abstract state. The reasons for using 
this form of upward simulation are explored in [2,7]. In particular, this form 
ensures that refinement corresponds to failures-divergences refinement in CSP. 
We need this form here since Lemma 2 does not hold for the weaker form of 
upward simulation. 

Given these definitions, one might assume that properties involving states 
of the abstract system would hold for the related states in the concrete system. 
That is, a property referring to abstract state s would hold for concrete state t 
when t was related to s. This is not the case, as the following example shows. 

Consider the following Z specification which, from an initial state s = 0, 
moves nondeterministically to either state s = 1 or s = 2 via operation AOpl 
and then to state s = 3 or state s = 4 depending on its current state via 
operation AOp2. 

AState Alnit. 

s : 0 . . . 4 AState 

s = 0 

AOpl 

AAState 

s = 0 A s' e {1,2} 

This is refined by the following specification which from an initial state t = 0 
moves to a state t = 1 via operation COp 1 and then nondeterministically to 
state t. = 2 or t = 3 via operation COp2. 

CInit 

CState 





t. = 0 
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r COp 1 _ 

AGState 



t = 0 A t' = 1 



COp 2 _ 

r AC State 



t = 1 A t' e {2,3} 



This can be proved to be a refinement using an upward simulation with the 
following retrieve relation. 

R 

AState 

CState 

s=0«(=0 
se{i,2}«t=i 
s = 3 t = 2 
s = 4 t = 3 



This can be seen more clearly in Figure 1 which depicts the behaviours of the 
specifications and the retrieve relation; with only the operations visible, both 
behaviours are identical. 



! AOp2 3 




Fig. 1 . An example refinement 



Some temporal properties that hold for the abstract specification also hold 
for the related states in the concrete specification. For example, the property 
“it is always true that when s = 0, s € {1,2} in the next state” holds for the 
abstract specification, and the corresponding property “it is always true that 
when t = 0, t = 1 in the next state” holds in the concrete specification. 

Note, however, that while the similar property “it is always true that when 
s = 1, s = 3 in the next state” holds for the abstract specification, the corre- 
sponding property “it is always true that when t = 1, t = 2 in the next state” 
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does not hold for the concrete specification. Hence, this property is not preserved 
under this refinement. 

This motivates the question as to when a temporal property is preserved 
by refinement. Does it depend on the property, the nature of the refinement or 
both? In the next section, we describe a general approach for answering this 
question for any temporal logic over states. 

3 Temporal Structures 

The temporal logics LTL, CTL and the /./-calculus are usually interpreted on 
temporal, or Kripke, structures [8]. Given the set of all atomic predicates AP, a 
temporal structure (S', So, Trans, L) comprises 

— a set of states S, 

— a set of initial states S 0 C S, 

— a transition relation Trans C S x S where \/ s £ S .3 s' £ S.(s,s') £ Trans, 

i.e., Trans is total, and 

— a labelling function L : S — > P AP mapping each state in S to the atomic 

propositions which hold in it. 

The condition that Trans is total is necessary and, together with an assumption 
that some transition always occurs, ensures that temporal structures continue 
to progress. 

To interpret temporal logic predicates on Z specifications, it is necessary to 
also adopt this assumption that the specified system progresses, i.e., that its 
environment always allows some enabled operation to eventually occur. It is also 
necessary to represent Z specifications as temporal structures. 

In order to state temporal properties which refer to inputs and outputs, 
we need to embed these in the states of the specification without changing its 
behaviour. This can be done as detailed in [13]. In brief, the type of each input 
and output when embedded in the state is extended with a value _L and this 
value is used for the pre-state value of embedded inputs and post-state value 
of embedded outputs when they are not declared in a particular schema of the 
original specification. 

The set S of the temporal structure representing a Z specification is the set 
of bindings of the state schema of the specification. For example, for the abstract 
specification of Section 2 

S = {s 0, s 1, s 2, s 3, s 4} 

Similarly, the set Sq is the set of bindings of the initial state schema. For the 
same example, 

So = {« 0 } 

The transition relation Trans includes mappings (s, s') : S x S when there 
exists an operation with binding s U s', and mappings (s,s) : S x S when there 
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does not exist an operation with binding sUs / for any s' : S . The latter mappings 
represent stuttering transitions when no other transitions are available. They are 
necessary for Trans to be total. For the example, 

Trans = {(s 0, s ^ 1), (s 0, s 2), (s 1, s 3), (s 2, s 4), 

(s 3, s 3), (s 4, s 4)} 

where the final two pairs are stuttering transitions. 

The labelling function L maps each binding s in S to the set comprising those 
atomic propositions P over the state variables where s is also a binding of the 
schema [AState \ P], For example, since s 0 is a binding of [AState \ s < 10], 
the proposition s < 10 is a member of L(s 0). 

3.1 Temporal Structures and Refinement 

Given the above representation of Z specifications as temporal structures, we 
can express that a Z specification A meets a temporal logic property P using 
the standard notation A t= P. This means that the property P holds from all 
initial states of the specification. 

To relate the temporal properties of Z specifications under a refinement, we 
first prove a lemma on Z refinement. 

Lemma 1. Given Z specifications, A and C , if A C C verified via a retrieve 
relation R then V CInit • (3 Alnit • R). 

Proof. Since downward and upward simulation are complete, C is either a 
downward or upward simulation of A, or a combination of the two. It suffices to 
consider each case separately. 

In the former case, we have from Definition 1 

V CState • CInit => (3 AState • Alnit A R) 

This simplifies to the required condition. 

In the latter case, we have from Definition 2 

V CState • 3 AState • R 
We also have 

V AState ; CState • CInit A R => Alnit 

Together these properties of upward simulation give us the required condition. □ 

For all temporal logics over states, the following general theorem holds. 

Theorem 1. Given Z specifications, A and C, and temporal logic property P, 
if A \= P and ACC under retrieve relation R then C t= 3 AState • P A R. 




124 



John Derrick and Graeme Smith 



Proof. From Lemma 1, we know that for each initial state of C there exists 
an initial state of A related to it by R. Hence, C t= 3 Alnit • R. Also since 
A 1= P, we know that P is true from all states satisfying Alnit. Hence, we have 
CN3 Alnit •PAR which implies the required condition. □ 

This general theorem provides the basis for our investigations. If a temporal 
logic property holds for a specification A, we want to know whether a correspond- 
ing property holds for a refinement C . We define a corresponding property to be 
one constructed from the same logical operators and with each atomic proposi- 
tion P replaced by the following representation of it in the concrete state: 

3 AState • P A R 

where R is the refinement retrieve relation. 

Determining whether this is true reduces to determining whether conjunction 
and existential quantification distribute through the operators in the temporal 
logic property in such a way that the resulting property is no stronger than the 
original. For example, suppose A 1= P A Q. From Theorem 1, we know that 

C \= 3 AState • {P A Q) A R 

Since conjunction distributes through conjunction resulting in an equivalent 
property (i.e., (P A R) A (Q A R) is equivalent to (P A Q) A R), we have 

C \= 3 AState • {P A R) A (Q A R) 

Since existential quantification distributes through conjunction resulting in a 
weaker property (i.e., (3 x • P) A (3 x • Q) is implied by 3 x • P A Q ), we have 

C t= (3 AState • P A R) A (3 AState • Q A R) 

If P and Q are atomic propositions then the above property is the concrete prop- 
erty corresponding to the abstract property P A Q. Hence, the abstract property 
is preserved by refinement. If P or Q involve additional operators then we need 
to repeat the above process on the relevant conjunct or conjuncts above. Note 
that these conjuncts are of the same form as the concrete property derived from 
Theorem 1 and so the distribution of conjunction and existential quantification 
is again required. 

In the following section, we investigate whether conjunction and existential 
quantification distribute through the operators of Linear Temporal Logic (LTL). 
This shows us when LTL properties are preserved by refinement and throws light 
on the cases when they are not. 

4 Linear Temporal Logic 

Linear Temporal Logic (LTL) [8] is defined on paths, i.e., infinite sequences of 
states of a temporal structure where each pair of consecutive states is related by 
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the transition relation of the temporal structure. In this context, A 1= P means 
that P holds on all paths originating from initial states of A. Given a path n of 
A, we also adopt the more specific notations A,n \= P and A,-Ki t= P for some 
i ^ 0. The former means that property P is true on path ir and the latter that 
the property is true on the suffix of path ir starting with its ith state, i.e., if 
7T — 5qSiS2 • • • • • • then 7Tj — S^ Sj_|_i S £_|_2 • ■ •• 

We introduce a further lemma on refinement. 

Lemma 2. Given Z specifications A and C , if A C C under retrieve relation 
R then for all paths 7 t g = tohfo ... of C there exists a path n A = S 0 S 1 S 2 • ■ • of A 
such that each state U of tt c is related to the corresponding state Sj of tt a by R. 

Proof. The proof follows by induction. 

(i) For state to, we know that there exists an abstract state related to it by 
Lemma 1. Hence, there is a path tt a = S 0 S 1 S 2 ... of H such that so and to are 
related by R. 

(ii) Assume there exists a path 7r A = S 0 S 1 S 2 • ■ ■ of A and a j : N such that 
for all i : N where i ^ j, Si is related to t, by R. Since downward and upward 
simulation are jointly complete, C is either a downward or upward simulation 
of A , or a combination of the two. It suffices to consider each case separately. 

In the former case, we have from Definition 1 

V A State; CState; CState' • R A COpi => (3 A State' • R' A AOpt) 

Hence, for any concrete transition from tj, there will be a transition from Sj to 
a state s j ' +1 such that t 1+i and .s' +] are related by R. The definition of a path 
means there will always be some transition from tj to tj + \. Hence, there is a 
path ty a ' = S 0 S 1 S 2 • • • s' +1 Sj +2 ... oi A such that for all i : N where i ^ j, Si is 
related to t t by R and sj +1 is related to tj + 1 by R. 

For upward simulation, we do not require the induction assumption. We 
simply prove that a path ir A = Sq s i s 2 • • ■ °f ^ exists such that for all i : N 
where * < j + 1, s' is related to fc, by R. 

We have from Definition 2 

V CState • 3 AState • R 

Hence, there will be an abstract state s' +1 related to tj+ 1 by R. Consider a 
concrete transition from tj to tj+ \. Either this is skip (when no concrete op- 
erations are enabled) or the concrete transition is due to a concrete operation 
COpi . In the former case the upward simulation applicability condition means 
no abstract operations are enabled, thus there exists a skip in the abstract state 
and tj = tj+i, Sj = Sj+i- In the latter case, we use the following condition from 
Definition 2 

V AState 1 -, CState ; CState 1 • COpt A R' => (3 AState • R A AOpt) 

Hence, for the concrete transition from tj to tj+ 1 due to COpi, there will be a 
transition from a state s' of A to Sj +1 such that s' is related to tj by R. 
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Similarly, for the concrete transition from tj- 1 to tj, there will be a transition 
from a state of A to s' such that Sj_ ± is related to tj- 1 by P. Following this 
line of reasoning, we can deduce that there exists a path n A ' = s(,s(s 2 . . . such 
that for all i : N such that * < j + 1, s' is related to t t by R. □ 

We also specialise Theorem 1 of Section 3.1 for LTL as follows. 

Theorem 2. Given Z specifications, A and C, and temporal logic property P, 
if there exists an i : N such that for all abstract paths i t a , A, w A 1= P and A C C 
under retrieve relation R then for all concrete paths n c , C,tt f b 3 AState • 
PAR. 

Proof. From Lemma 2, we know that for each concrete path tt c = totifa . ■ . of 
C there exists an abstract path tt a = S0S1S2 ■ ■ . of A such that for all i : N, Sj is 
related to t, by R. Hence, C , nf b 3 A State • R where one instance of AState 
satisfying the existentially quantified predicate is Si. Also since A,tt a t= P, we 
know that P is true from state s, . Hence, we have C, tt g t= 3 AState • P A R as 
required. □ 



4.1 Syntax and Semantics 

Formulae in LTL are generated from the following rules of syntax, 
atomic propositions are formulae 1 

if P and Q are formulae, then — P and P A Q are formulae 
if P and Q are formulae, then X P and P U Q are formulae 



The operator X is read as “next” and U as “until”. The following abbrevia- 
tions are also commonly used: 



FV Q 


= -'(-■Pa 


- 1 Q) 


P => Q 


= -i P V Q 




true 


= FV-F 


for some P 


false 


= P A -> P 


for some P 


F P 


= true U P 


(read “eventually P”) 


G P 


= -■ F -> P 


(read “always P”) 



The semantics of LTL is given in terms of a temporal structure A , path 
7r = S 0 S 1 S 2 • • • of A, and LTL formulae P and Q as follows. 



A, 7T t= P 
A, 7T t= -1 P 
A, 7r 1= P A Q 
A,ttNX P 
A, 7rb P U Q 



if and only if 
if and only if 
if and only if 
if and only if 
if and only if 



P is true in s 0 
A, 7Tb P 

A, 7T t= P and A, tt \= Q 
A, 7Ti t= P 

3j.(A,TTj b Q) and Vfc <j.(A, irk b P) 



1 LTL, as used in model checking, is usually restricted to atomic propositions of the 
form n = v. We do not require this restriction for our results; any proposition is 
allowed. 
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4.2 Property Preservation 

Let A and C be Z specifications such that ACC under retrieve relation R. 
To determine which LTL properties of A are preserved under Z refinement, we 
examine the distribution of conjunction and existential quantification through 
each LTL operator in turn. That distribution through conjunction works was 
shown in Section 3.1. Of the other operators (surprisingly) negation, rather than 
one of the temporal operators, turns out to be the most interesting case and so 
we leave it until last. 

Next (X). If A 1= X P then from the semantics of the next operator, for all 
abstract paths tt a , we have 

A,-k a \=P 

Hence, from Theorem 2 we have, for all concrete paths n c , 

C, wf 1= 3 AState • P A R 

Hence, from the semantics of the next operator, we have 
dtX (3 AState •PAR) 

Hence, conjunction and existential quantification distribute through the next 
operator. 

Until (U). If A t= P U Q then from the semantics of the until operator, we 
know there exists a j : N such that for all k : N such that k < j, for all abstract 
paths t : a , we have 

A,n£\=P 

and 

A,irf t= Q 

Hence, from Theorem 2 we have, for all concrete paths n c , 

C, \= 3 AState • P A R 

and 

C, 7i \= 3 AState • Q A R 

Hence, from the definition of the until operator, we have 

C t= (3 AState • P A R) U (3 AState • Q A R) 

That is, conjunction and existential quantification distribute through the until 
operator. 

Since the eventually operator (F) is defined in terms of the until operator, 
conjunction and existential quantification also distribute through it. 
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Negation (— i ) 

Negation of a property distributes through conjunction with a retrieve relation. 
That is, -i P A R implies -> (P A R). However, it does not distribute through 
existential quantification. That is, 3 x • -> P does not imply -> (3 x • P) (since 
there may be some values of x satisfying -i P and others satisfying P). 

So, in general, LTL properties involving negation are not preserved by refine- 
ment. Consider, for example, the following Z specification which performs Op 1 
once and then Op2 an infinite number of times. 



AState 

fs : N 



AOpl 

AAState 

s = 0 A s' = 1 



. Alnit _ 
AState 



s = 0 



_AOp2 

AAState 



s/0As' = s+ l 



It is refined by the following specification with identical behaviour. 



CState _ 

* : { 0 , 1 } 



CInit 
\ t = 0 



r COp 1_ 
ACState 



t, = 0 A t’ = 1 



COp2_ 

ACState 



t = 1 A t' = 1 



The refinement is a downward simulation under the retrieve relation 

R 

AState 

CState 



s = 0 t = 0 

s yA 0 t = 1 



However, while the LTL property G (s = 1 => X (-> s = 1)) holds for the 
abstract specification, the corresponding property G (t = 1 => X (-i t = 1)) 
does not hold for the concrete specification. 

This result does not mean that LTL properties involving negation are never 
preserved by refinement. For example, the property G(s = 0=>X(->s = 
0)) holds for the abstract specification above, and the corresponding property 
G (t = 0 => X (-i t = 0)) holds for the concrete specification. 
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The reason, in this case, is that the retrieve relation R is functional for 
the state t = 0, i.e. , there is only one related abstract state. When this is so, 
3 AState • -i P A R implies that -> P is true from the single instance of AState 
related to the concrete state. Hence, it is equivalent to -■ (3 AState •PAR). 
That is, negation distributes through existential quantification. 

Also, even without the retrieve relation being functional on negated states, 
some LTL properties involving negation are preserved. For example, disjunc- 
tion which is defined in terms of negation does distribute through existential 
quantification as follows. 

3 x • P V Q 
= 3i«t(^PA^Q) 

= ^ (Vi • ^ P A ^ Q) 

^ -> ((V x • ^ P) A (Vir • ^ Q )) 

= n(b (3 & • P)) A (~i (3 s. Q))) 

= (3 x • P) V (3 x • Q) 

In fact, whenever we have an even number of successive negations to dis- 
tribute, as above, then they will distribute through existential quantification. 
The proof follows the reasoning of that above. Therefore, as well as the disjunc- 
tion operator, we have that conjunction and existential quantification distribute 
through the always operator which is defined byG P = ^ F -> P. 

Of the operators defined as abbreviations, the only one we haven’t considered 
is implication. Since this is defined by P =A Q = -i P V Q, we have an odd num- 
ber of successive negations preceding predicate P. For this reason, the operator 
does not distribute through existential quantification, and hence temporal logic 
properties involving implication are not, in general, preserved by refinement. 

This explains the example at the end of Section 2. The first concrete property 
can be formulated in LTL as 

G(s = 0=tX(s£ {1,2})) 

which despite involving implication is preserved by the refinement since the 
retrieve relation is functional on t = 0 (the concrete state related to So)- 
The second property can be formulated in LTL as 

G((s = U(Xs = 3)) 

In this case, the retrieve relation is not functional on state t = 1 (the concrete 
state related to s = 1) and so the property is not preserved. 

5 Conclusion 

In this paper, we have shown that all temporal properties P over the state AState 
of an abstract Z specification A are transformed to properties 3 AState • P A R 
over a concrete Z specification C which is a refinement of A under the retrieve 
relation R. 
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This result allowed us to reduce the problem of determining when properties 
of a given temporal logic are preserved by refinement to an investigation of the 
distribution of the various operators of the temporal logic through conjunction 
and existential quantification. 

We carried out such an investigation for Linear Temporal Logic (LTL) and 
discovered that while properties containing only conjunction and the temporal 
operators “next” and “until” (and, hence, also the derived operator “eventually”) 
are preserved, those involving negation are, in general, not preserved. 

We also pointed out two important cases when properties involving negation 
are preserved. The first is when any negated concrete state is related to only 
one abstract state. The second is when the number of successive negations in 
any part of the property is even. The first case is important as it shows that all 
LTL properties are preserved when the refinement retrieve relation is functional. 
The second is important as it shows that properties involving certain operators 
derived using negation, namely, disjunction and the temporal operator “always”, 
are preserved. 

The preservation of all LTL properties under a functional retrieve relation 
agrees with the recent result by Darlot et al. [5]. Our work extends this result 
by considering non-functional retrieve relations and also a complete definition 
of refinement (Darlot et al. consider only a variant of downward simulation in 
their approach). 

We used a form of upward simulation that is compatible with CSP refinement, 
and is slightly stronger than the form often used in Z. The extension of our results 
to the weaker form of upward simulation is left for future work. 

Our work is also closely related to that on abstraction, relevant in model 
checking as a means to reduce the size of the state space of a specification to 
be checked. Such techniques are in essence the inverse of refinement. Clarke 
et al. [3] proved that all properties in the universal fragment of CTL* (i.e., the 
fragment of CTL*, an extension of CTL, which excludes existential quantification 
over paths) are true of a specification when they are true of an abstraction of 
that specification. Loiseaux et al. [11] proved a similar result for the universal 
fragment of the raw-calculus. Both of these fragments subsume LTL, but there 
is no contradiction with our result as only functional abstraction relations were 
considered. 

The abstraction results, as well as being limited to functional relations, also 
only consider variants of downward simulation. It would be interesting, therefore, 
to extend our results to CTL and the /z-calculus. Not only would this make our 
approach of using temporal properties with Z more general, and compatible with 
more model checking techniques, it would also open the possibility of developing 
more general abstraction techniques for model checking. This extension of our 
results could readily be achieved using the approach we have presented in this 
paper. 
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Abstract. JavaFAN uses a Maude rewriting logic specification of the 
JVM semantics as the basis of a software analysis tool with competitive 
performance. It supports formal analysis of concurrent JVM programs 
by means of symbolic simulation, breadth-first search, and LTL model 
checking. We discuss JavaFAN’s executable formal specification of the 
JVM, illustrate its formal analysis capabilities using several case studies, 
and compare its performance with similar Java analysis tools. 



1 Introduction 

There is a general belief in the algebraic specification community that all tra- 
ditional programming language features can be described with equational spec- 
ifications [2,9,29]. What is less known, or tends to be ignored, is that concur- 
rency, which is a feature of almost any current programming language, cannot 
be naturally handled by equational specifications, unless one makes determinis- 
tic restrictions on how the different processes or threads are interleaved. While 
some of these restrictions may be acceptable, as most programming languages 
also provide thread or process scheduling algorithms, most of them are unac- 
ceptable in practice because concurrent execution typically depends upon the 
external environment, which is unpredictable. Rewriting logic [17] extends equa- 
tional logic with rewriting rules and has been mainly introduced as a unified 
model of concurrency ; indeed, many formal theories of concurrency have been 
naturally mapped into rewriting logic during the last decade. 

A next natural challenge is to define mainstream concurrent programming 
languages in rewriting logic and then use those definitions to build formal anal- 
ysis tools for such languages. There is already a substantial body of case studies, 
of which we only mention [25, 24, 28], backing up one of the key claims of this pa- 
per, namely that rewriting logic can be fruitfully used as a unifying framework for 
defining programming languages. Further evidence on this claim includes model- 
ing of a wide range of programming language features that has been developed 
and tested as part of a recent course taught at the University of Illinois [22] . In 
this paper we give detailed evidence for a second key claim, namely that rewrit- 
ing logic specifications can be used in practice to build simulators and formal 
analysis tools for mainstream programming languages such as Java with com- 
petitive performance. Here, we focus on Java’s bytecode, but our methodology 
is general and can be applied also to the Java source code level and to many 
other languages. 



C. Rattray et al. (Eds.): AMAST 2004, LNCS 3116, pp. 132-147, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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The JavaFAN (Java Formal Analyzer) tool specifies the semantics of the 
most commonly used JVM bytecode instructions (150 out of the 250 total) as a 
Maude module specifying a rewrite theory Tjvm = (Vjvm> Ejym, -Rjvm), where 
(Ajvmj -Ejvm) is an equational theory giving an algebraic semantics with se- 
mantic equations Tjvm t° the deterministic JVM instructions, whereas .Rjvm 
is a set of rewrite rules , with concurrent transition semantics, specifying the be- 
havior of all concurrent JVM instructions. The three kinds of formal analysis 
currently supported in JavaFAN are: (1) symbolic simulation , where the theory 
Tjvm is executed in Maude as a JVM intepreter supporting fair execution and 
allowing some input values to be symbolic; (2) breadth-first search, where the 
entire, possibly infinite, state space of a program is explored starting from its 
initial state using Maude’s search command to find safety property violations; 
and (3) model checking , where if a program’s set of reachable states is finite, lin- 
ear time temporal logic (LTL) properties are verified using Maude’s LTL model 
checker. 

A remarkable fact is that, as we explain in Section 4, even though Tjvm gives 
indeed a mathematical semantics to the JVM, it becomes the basis of a formal 
analysis tool whose performance is competitive and in some cases surpasses that 
of other Java analysis tools. The reasons for this are twofold. On the one hand, 
Maude [3] is a high-performance logical engine, achieving millions of rewrites 
per second on real applications, efficiently supporting search, and performing 
model checking with performance similar to that of SPIN [13]. On the other, the 
algebraic specification of system states, as well as the equations Ejym and rules 
i?jVM> have been optimized for performance through several techniques explained 
in Section 3.5, including keeping only the dynamic parts of the state explicitly 
in the state representation, and making most equations and rules unconditional. 
In this regard, rewriting logic’s distinction between the equations Ejym and 
the rules -Rjvm has a crucial performance impact in drastically reducing the 
sate space size. The point is that rewriting with the rules .Rjvm takes place 
modulo the equations Ejym, and therefore only the rules -Rjvm affect state space 
size. Our experience in specifying the JVM in rewriting logic is that we gain 
the best benefits from algebraic (equations) and SOS [20] (Rules) paradigms 
in a combined way, while being able to distinguish between deterministic and 
concurrent features in a way not possible in either SOS or algebraic semantics. 

Related Work. The different approaches to formal analysis for Java can be 
classified as focusing on either sequential or concurrent programs. Our work falls 
in the second category. More specifically, it belongs to a family of approaches 
that use a formal executable specification of the concurrent semantics of the JVM 
as a basis for formal reasoning. Two other approaches in precisely this category 
are one based on the ACL2 logic and theorem prover [15], and another based 
on a formal JVM semantics and reasoning based on Abstract State Machines 
(ASM) [23]. Our approach seems complementary to both of these, in the sense 
that it provides new formal analysis capabilities, namely search and LTL model 
checking. The ACL2 work is in a sense more powerful, since it uses an inductive 
theorem prover, but this greater power requires greater expertise and effort. 




134 Azadeh Farzan, Jose Meseguer, and Grigore Ro§u 



Outside the range of approaches based on executable formal specification, but 
somewhat close in the form of analysis, is NASA’s Java Path Finder (JPF) [1, 12] , 
which is an explicit state model-checker for Java bytecode based on a modified 
version of a C implementation of a JVM. Preliminary rough comparisons of 
JavaFAN and JPF 1 are encouraging, in the sense that we can analyze the same 
types of JVM programs of the same or even larger size. Other related work 
includes [21], which proposes an algorithm that takes the bytecode for a method 
and generates a temporal logic formula that holds iff the bytecode is safe; an 
off-the-shelf model checker can then be used to determine the validity of the 
formula. Among the formal techniques for sequential Java programs, some related 
approaches include the work on defensive JVM [5], and the collective effort 
around the JML specification language and verification tools for sequential Java, 
e.g. [16,26]. 

Another approach to define analysis tools for Java is based on language trans- 
lators, generating simpler language code from J ava programs and then analyzing 
them later. Bandera [6] extracts abstract models from Java programs, specified 
in different formalisms, such as Promela, which can be further analyzed with 
specialized tools such as SPIN. JCAT [7] also translates Java into PROMELA. 
[19] presents an analysis tool which translates Java bytecode into C++ code 
representing an executable version of a model checker. While the translation- 
based approaches can benefit from abstraction techniques being integrated into 
the generated code, they inevitably lead to natural worries regarding the cor- 
rectness of the translations. Unnecessary overhead seems to be also generated, at 
least in the case of [19]; for example, exactly the same Remote Agent Java code 
that can be analyzed in 0.3 second in JavaFAN [8] takes more than 2 seconds 
even on the most optimized version of the tool in [19]. 

In section 2 we present a brief background on Maude’s methodology. A de- 
tailed description of our model is given in 3. In Section 4, we present the various 
kinds of formal analysis done for the Java programs together with the perfor- 
mance results for several case studies. Finally, Section 5 presents the conclusion 
and future work. 



2 Rewriting Logic, Maude and Its Object Methodology 

Here we briefly explain our methodology to specify the state of a concurrent 
system, in this case focusing on the JVM, as a “pool” or “soup” of objects 
whose interaction is modeled by rewrite rules. As a whole, the specification of 
the JVM is a rewrite theory, that is, a triple (Ujvm> £jvm, -Rjvm), with Ujvm a 
signature of operators, -Ejvm a set of equational axioms, and Rjvm a collection 
of labeled UjvM-rewrite rules. The equations describe the static structure of 
the JVM’s state space as an algebraic data type, as well as the operational 
semantics of its deterministic features. The concurrent transitions that can occur 
in different threads are described by the rules Rjvm- Arbitrary interleavings 
of rewrite rules are possible, leading to different concurrent computations of a 

1 Authors thank Willem Visser for examples and valuable information about JPF. 
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multithreaded JVM program. The rewriting rules J?jvm are applied modulo the 
equations -Ejvm- Important equations are those of associativity , commutativity 
and identity (ACU) of binary operations - such as the multiset union operation 
that builds up the “soup” of objects - allowing us to effectively define the state 
infrastructure of the JVM. Even though we focus on the algebraic definition of 
the JVM in this paper, the same methodology has been used to define the Java 
language as well as several other programming languages [8,22], 

Maude [3] supports, executes, and formally analyzes rewriting logic theo- 
ries, via a series of efficient algorithms for term rewriting, state-space breadth- 
first search, and linear temporal logic (LTL) model checking. Once the JVM 
is formally specified as a rewrite theory in Maude, the above provide us with 
JVM program analysis tools at no additional cost, capable of performing fair 
interpretation and simulation, potentially infinite state-space exploration for de- 
tecting safety violations, as well as LTL model-checking of JVM multithreaded 
programs. FTjvm contains associativity, commutativity and identity equational 
axioms to represent the concurrent state of the JVM computation as a multiset 
of entities such as the threads, Java classes, Java objects, etc. Following a well- 
established methodology in rewriting logic, for which Maude provides generic 
support [3], we call these entities objects. To avoid terminology confusion with 
Java objects, we may sometimes call them Maude objects. Unless differently 
specified, from now on by “object” we mean a “Maude object”. Maude sup- 
ports a fully generic object-oriented specification environment, where one can 
define classes and then objects as instances of classes. Aiming at a maximum 
of efficiency for our JVM analysis tools, we decided not to use Maude’s generic 
00 meta-level framework and, instead, to define a minimal object infrastructure 
at the core level. As a consequence, we have dropped the generic definition of 
classes, “hardwiring” our object types according to the JVM language. 

Most of our equations and rules are applied modulo ACU, which in Maude 
is a highly optimized and efficient process. For example, Figures 3 and 4 present 
typical object-oriented rewrite rules. An object in a given state is formally rep- 
resented as a term (O : C | cq : v \, . . . , a n : v n ), where O is the object’s name or 
identifier, C is its class, the cq’s are the names of the object’s attribute identifiers, 
and the vfs are the corresponding values. 

3 Rewriting Logic Semantics of the JVM 

We use Maude to specify the operational semantics of a sufficiently large subset 
of JVM bytecode. This includes 150 out of 250 bytecode instructions, defined in 
about 2000 lines of Maude code, including around 300 equations and 40 rewrite 
rules. We support multithreading, dynamic thread and object creation, virtual 
functions, recursive functions, inheritance, and polymorphism. Exception han- 
dling, garbage collection, native methods and many of the Java built-in libraries 
are not supported in the current version. The formal semantics of each instruc- 
tion is defined based on the informal description of JVM in [27]. Section 3.2 
explains the operational semantics of the deterministic part of the JVM given 
by the 300 equations in £jvm, and Section 3.3 discusses the semantics of the 
concurrent part of JVM specified by the 40 rewrite rules in J?jvm- 
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3.1 Algebraic Representation of the JVM State 

Here, we describe the representation of states in our model. Our major design 
goal has been to reduce the size and the number of system states to improve 
the performance of the formal analysis. The reduction in size has been achieved 
through separating the static and dynamic aspects of the program, maintaining 
only the dynamic part in the system’s state. To reduce the number of states, 
we keep the number of rewrite rules in the specification minimal. A detailed 
discussion on these optimizations is given in Section 3.5. 

The JVM has four basic components: (1) the class space, (2) the thread 
space, (3) the heap, and (4) the state transition machine, updating the internal 
state at each step. 

In our model, no specific entity plays the role of the state transition system, 
and the strict separation of the classes, threads, and objects no longer exists. In- 
stead, the state of the JVM is represented as a multiset of objects and messages 2 
in Maude [3]. Rewrites (with rewrite rules and equations) model the changes in 
the state of the JVM. 



Elements of the Multiset. Objects in the multiset fall into four categories: 

1. Maude objects which represent Java objects, 

2. Maude objects which represent Java threads, 

3. Maude objects which represent Java classes, and 

4. auxiliary Maude objects used mostly for definitional purposes. 

Below, we discuss each in detail. 



Java Objects are modeled by objects containing the following attributes. 



< 0:Java0bject I Addr: Heap Address, FieldValues :FieldValues , CName : ClassName , Lock: Lock > 



The Addr attribute refers to the heap address at which the object is stored. 
Physical heap addresses are employed only because they are used in the bytecode 
to refer to objects. The FieldValues attribute contains all instance fields and 
their values. Note that a single field may have more than one value, depending 
on its appearance in more than one class in the hierarchy of superclasses of the 
Java class from which the object is instantiated. The sort FieldValues is a list 
of pairs, with each pair consisting of a class name and a list. The latter list by 
itself consists of pairs of field names and field values. Therefore, based on the 
current class of the object, we can extract the right value for a desired field. The 
CName attribute holds the name of the object’s class. The Lock attribute holds 
the lock associated with the object. 

2 Messages are used as a method to define the semantics in our model. One can use a 
somewhat different approach which does not include any messages. 
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Java Threads are modeled by objects with the following attributes. 

< T : JavaThread I callStack: CallStack, Status: CallStackStat , ORef : HeapAddress > 

The callStack attribute models the runtime stack of threads in Java. It is a 
stack of frames, where each frame models the activation record of a method 
call. Therefore, at any time, the top frame corresponds to the activation record 
of the method currently being executed. A frame is a tuple defined as follows. 

op : Int Inst LabeledPgm LocalVars OperandStack SyncFlag ClassName -> Frame . 

The first component is an integer representing the program counter. The sec- 
ond component is the next instruction of the thread to be executed. The third 
component is a complete list of the instructions of the method, along with their 
corresponding offsets. The fourth component is the list of the current values 
of the local variables of the method. The fifth component contains the current 
operand stack, which carries instruction arguments and results. The sixth com- 
ponent is a flag indicating whether the call of the current method has locked the 
corresponding class (SLOCKED) or the corresponding object (LOCKED) or noth- 
ing at all (UNLOCKED). The last component represents the class from which the 
method has been invoked. 

The Status attribute is a flag indicating the scheduling status of the thread: 
scheduled when the thread is ready to execute the next instruction, or waiting 
otherwise. Examples of threads with waiting status include a thread waiting for 
the completion of a communication it has started in order to get the code of the 
method being invoked. The Oref attribute contains the address of the object to 
which the thread is associated. 

Java Classes. Each class is divided into static and dynamic parts (see Sec- 
tion 3.5), represented by JavaClassS and JavaClassD objects respectively. 
These objects contain the following attributes. 

< C: JavaClassS I SupClass:ClassName,StaticFields:FlatFNL,Fields:FlatFNL,Methods:MethodList > 

< C’ : JavaClassD I ConstPool:ConstantPool, Lock:Lock, StaticFieldValues :FieldPairList > 

The SupClass attribute contains the name of the immediate superclass of the 
class represented. The attribute StaticFields is a list of pairs, each pair con- 
sisting of a class name along with the list of static field names of that class. 
The classes in the first components of the pairs in this list are exactly the class 
represented by this object along with all its ancestors. These lists are compiled 
in a preprocessing phase. The Fields attribute has exactly the same structure 
as StaticFields, but for instance fields. The ConstPool attribute models the 
constant pool in the Java class file. In our model the constant pool is an indexed 
list containing information about methods, classes, and fields. Bytecode instruc- 
tions refer to these indices, that the threads use to extract (from the constant 
pool) the required information to execute the instructions. By looking at the itli 
entry of the constant pool, we get a Fieldlnf o, which contains a field name and 
the name of the class the field belongs to, or a Methodlnfo, which contains the 
method name, the name of the class the method belongs to, and the number of 
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arguments of the method, or a Classlnfo, which only contains a class name. 
Examples of instructions which refer to the constant pool include, 

— new #5, which creates a new object of the class whose name can be found 
in the 5th element of the constant pool, or 

— invokevirtual #3, which invokes a method whose information (name, 
class, and number of arguments) can be found at the 3rd entry of the con- 
stant pool. 

The Methods attribute contains a list of tuples, each representing a method. The 
structure of the tuple is as follows: 

op : MethodName MethodFormals MethodSync LabeledPgm Int -> Method . 

The tuple components respectively represent the method name, a list of types of 
formal arguments of the method, a flag indicating whether or not the method is 
synchronized, the code of the method, and the number of local variables of the 
method. The StaticFieldValues attribute is exactly the same as FieldValues 
already discussed for JavaObject, except that this list refers to the values of 
static fields (which are stored inside the class) as opposed to the values of instance 
fields (which are stored inside the object). The Lock attribute holds the lock 
associated with the class. 

Auxiliary Objects: Several objects in the multiset do not belong to any of the 
above categories. They have been added for definitional/implementation pur- 
poses. Examples include: 

1. An object collecting the outputs of the threads. This object contains a list of 
values. When a thread prints a value, it adds this value to the end of this 
list. Input is assumed to be hardwired in the Java program at the moment. 

2. A heap manager , that maintains the last address being used on the heap. 
We do not model garbage collection at the moment, but a modification of 
the heap manager can add garbage collection to our current JVM definition. 

3. A thread name manager , that is used to generate new thread names. 

4. There are several Java built-in classes that had to be apriori defined. The 
support for input/output, creating new threads, and wait/notify facilities 
are among the most important ones. All of these built-in classes have been 
created separately and are added as part of the initial multiset. 



3.2 Equational Semantics of Deterministic JVM Instructions 

If a bytecode instruction can be executed locally in the thread, meaning that no 
interaction with the outside environment is needed, that instruction’s semantics 
can be specified using only equations. The equations specifying the semantics of 
all these deterministic bytecode instructions form the Ejvm part of the JVM’s 
rewrite theory. In this section we present some examples of how deterministic 
bytecode instructions are modeled in our system. The complete Maude repre- 
sentation and a collection of examples can be found in [8] . 
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eq < T : JavaThread I callStack: [PC, iadd, Pgm, LocalVars, (I # J # OperandStack) , 

SyncFlag, ClassName] CallStack, Status: scheduled, ORef : OR > 

= < T : JavaThread I callStack: [PC + size (Pgm [PC] ) , Pgm [PC + size (Pgm [PC] )] , Pgm, LocalVars, 
((I + J) # OperandStack), SyncFlag, ClassName] CallStack, Status: scheduled, ORef: OR > . 



Fig. 1. The iadd instruction. 



iadd instruction is executed locally in the thread, and therefore, is modeled by 
the equation shown in Figure 1. Values I and J on top of the operand stack are 
popped, and the sum I + J is pushed. The program counter is moved forward 
by the size of the iadd instruction to reach the beginning offset of the next 
instruction. The current instruction (which was iadd before) is also changed to 
be the next instruction in the current method code. Nothing else is changed in 
the thread. Many of the bytecode instructions are typed. In this example, by 
defining I and J to be integer variables, we support dynamic type checking as 
well. Several dynamic checks of this kind are supported. 



Invokevirtual is used to invoke a method from an object. It is among the most 
complicated bytecode instructions and its specification includes several equations 
and rewrite rules. The equation in Figure 2 is the first part of invokevirtual 
semantics. One thread, one Java object, and one Java class are involved. When 



ceq < T : JavaThread I callStack: [PC, invokevirtual (I) , Pgm, LocalVars, OperandStack, 
SyncFlag, ClassName] CallStack, Status: scheduled, ORef: OR > 

< ClassName : JavaClassV I StaticFieldValues : SFV, , Lock: L 

ConstPool : [I , {J, MethodName, CName]] ConstantPool > 

< 0 : JavaObject I Addr: K , FieldValues: FV, CName: CIName, Lock: L > 

= < T : JavaThread I callStack: [PC, invokevirtual (I ) , Pgm, LocalVars, OperandStack, 

SyncFlag, ClassName] CallStack, Status: waiting, ORef: OR > 

< ClassName : JavaClassV I StaticFieldValues: SFV, Lock: L, 

ConstPool: [I, {J, MethodName, CIName]] ConstantPool > 

< 0 : JavaObject I Addr: K, FieldValues: FV, CName: CIName, Lock: L > 

(GetMethod MethodName ofClass CIName ArgSize J forThread T) 

if K==int ( (popLocalVars(J+l , OperandStack) ) [0] ) . 



Fig. 2. The invokevirtual instruction. 



the thread reaches the invokevirtual instruction, by looking at the reference 
on top of the operand stack (REF(K)), it figures out from what object it has 
to call the method. The method information (see Section 3.1) will be extracted 
from the constant pool. The class ClassName needs to be involved, since the 
constant pool is stored inside this class. The class (CIName) is the current 3 class 
of the object 0, therefore the code of the desired method should be extracted 
from the constant part of it. The thread will send a message asking for the 
code of the method, sending all the information to uniquely specify it. The last 
entity before the condition is a message. This message is consumed later and the 

3 Note that this can change dynamically. 
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desired method is sent back to the thread through another message. The thread 
receives the message, and that is when the invocation is complete. If the method 
being invoked is a synchronized method, the thread has to acquire a lock before 
the invocation is complete. This then has to be done using a rewrite rule (see 
Section 3.5). 

3.3 Rewriting Semantics of Concurrent JVM Instructions 

The semantics of those bytecode instructions that involve interaction with the 
outside environment is defined using rewrite rules, thus allowing us to explore 
all the possible concurrent executions of a program. In this section we present 
the semantics of several concurrent bytecode instructions. 

monitorenter (Figure 3) is used to acquire a lock. This makes a change in 
the shared space between threads, and so has to be specified by a rewrite 
rule. One Java object and one Java thread are involved. The thread execut- 



rl [M0NIT0RENTER1] : 

< T : JavaThread I callStack: [PC, monitorenter, Pgm, LocalVars, (REF(K) # OperandStack) , 
SyncFlag, ClassName] CallStack, Status: scheduled, ORef : OR > 

< 0 : JavaObject I Addr: K, Lock: Lock (OIL, NoThread, 0), REST > 

=> < T : JavaThread I callStack: [PC + size (Pgm [PC] ) , Pgm[PC + size (Pgm [PC] )] , Pgm, 

LocalVars, OperandStack, SyncFlag, ClassName] CallStack, Status: scheduled, ORef : OR > 

< 0: JavaObject I Addr: K, Lock: Lock (OIL, T, 1), REST > . 



Fig. 3. The monitorenter instruction. 

ing monitorenter acquires the lock of the object whose reference is on top of 
the operand stack (REF(K)). The heap address of the object (K) is matched with 
this reference, and the lock of the object is changed to indicate that the object 
is now locked once by the thread T (note that a thread can lock or unlock an 
object several times). See section 3.4 for a more detailed discussion on locking 
and unlocking procedures. 

getfield is a more complex instruction modeled by the rewrite rule in Figure 4. 
One thread and two Java classes are involved in this rule. The I operand is 
an index to the constant pool referring to the field information ([I, {CIName, 
fieldname}] ), namely, field’s name and its corresponding class name. The Java 
class ClassName is needed to extract the constant pool. The Java object 0 is 
identified by matching its heap address K with the reference REF(K) on top of 
the operand stack. On the right hand side of the rule, the thread proceeds to the 
next instruction, and the value of the indicated field of object 0 is placed on top 
of the operand stack of the thread (FV [CIName , FieldName] # OperandStack). 

3.4 Synchronization 

We support three means of thread synchronization: (1) synchronized sections, 
(2) synchronized methods, and (3) wait/notifyAll methods. In this section 
we explain how these means of synchronization are modeled. 
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rl [GETFIELD] : 

< T : JavaThread I callStack : ([PC, getf ield(I) , Pgm, LocalVars, REF(K) # OperandStack, 
SyncFlag, ClassName] CallStack), Status: scheduled, ORef : OR > 

< ClassName : JavaClassV I ConstPool: ([I, {ClName, FieldName}] ConstantPool) , REST > 

< 0 : JavaObject I Addr: K, FieldValues: FV, REST’ > 

=> < T : JavaThread I callStack: ([PC + size (Pgm [PC] ) , Pgm [PC + size (Pgm [PC] )] , Pgm, 

LocalVars, (FV[ClName, FieldName] )#OperandStack, SyncFlag, ClassName] CallStack), 
Status: scheduled, ORef: OR > 

< ClassName : JavaClassV I ConstPool : ([I, {CIName, FieldName}] ConstantPool), REST > 

< 0 : JavaObject I Addr: K, FieldValues: FV, REST’ > 



Fig. 4. getfield Instruction. 



The synchronized sections in Java are translated into sections surrounded 
by monitorenter (see Figure 3) and monitorexit bytecode instructions. Dur- 
ing the execution of both, an object reference is expected to be on top of the 
operand stack whose corresponding lock is acquired and released respectively. 
Each Java object is modeled by a Maude object that includes a Lock attribute. 
This attribute has a tuple structure of the following form: 

op Lock : OidList Oid Int -> Lock . 

The first component is a list of identifiers of all threads that have waited on 
this object. This corresponds to wait and notifyAll methods (see below). The 
second component shows what thread currently owns the lock of this object 
(NoThread if none). The third component is a counter that shows how many 
times the owner of the lock has acquired the lock, since each lock can be acquired 
several times by the same owner. 

When a thread encounters the monitorenter instruction, it checks whether 
the lock of the corresponding object is free. If so, the lock is changed to belong to 
this thread, and the thread can proceed to the critical section. It is also possible 
that the lock is not free, but has been acquired by the same thread before. In 
this case, only the counter is increased by one. When the thread finishes the 
execution of the critical section and reaches the monitorexit instruction, it 
simply decreases the counter by one. If the counter becomes zero, the lock is 
marked as free. 

The synchronized methods are modeled in a very similar way. The differ- 
ence is that, when the method is synchronized, monitorenter and monitorexit 
are replaced by method invocation and return, respectively. These methods are 
modeled through different rewrite rules, since different bytecode instructions are 
used for them. 

Adding support (with little effort) for the wait and notifyAll methods of 
the Java built-in class Object is an interesting problem that we have solved. Sim- 
ilar to synchronization primitives, wait and notifyAll are called expecting an 
object reference on top of the operand stack. The thread (calling these methods) 
should already own the lock of the object on top of the operand stack. When 
wait is called, the thread releases the lock of the corresponding object, which 
it must own, and goes to sleep. It will not continue unless notified by another 
thread. The lock of the object is marked as free, the identifier of the current 
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thread is added to the list of threads waiting on this object (the first compo- 
nent of the lock), and the integer indicating the number of times the thread had 
locked the corresponding object is stored locally in the sleeping thread, so that 
it can be recalled when the thread wakes up. 

When notifyAll is called, a (broadcast) message is created containing the 
list of all threads which have waited on the corresponding object up to that 
point. This message will then be consumed by all the threads in this list. Each 
thread that consumes the message will try to wake up. In order to continue their 
execution, all these threads have to compete to acquire the lock on the specific 
object, to follow the rest of their executions inside the synchronized section. 
After the lock becomes available, one thread nondeterministically 4 acquires it. 

3.5 Optimizations 

Below, we discuss two major optimizations we have applied to decrease the size 
and number of system states, as well as the size of the state space. 

Size of the State. In order to keep the state of the system small, we only 
maintain the dynamic part of the Java classes inside the system state. Every 
attribute of Java threads and Java objects can potentially change during the 
execution, but Java classes contain attributes that remain constant all along, 
namely, the methods, inheritance information, and field names. This, potentially 
huge amount of information, does not have to be carried along in the state of the 
JVM. The attributes of each class are grouped into dynamic and static attributes. 
The former group appears in the multiset, and the latter group is kept outside 
the multiset, in a Maude constant accessed through auxiliary operations. 

Rules vs. Equations. Using equations for all deterministic computations, and 
rules only for concurrent ones leads to great savings in state space size. The 
key idea is that the only two cases in which a thread interacts with (possibly 
changes) the outside environment are shared memory access and acquiring locks. 
Examples of the former include the semantics of the instruction getf ield (see 
Section 3.3) where a rule has been used. As an example for the latter case, we 
refer the reader to semantics of the monitorenter instruction (see Section 3.3). 
Since only the 40 rules in J?jvm contribute to the size of the state space, which is 
basically a graph with states as nodes and rewrite transitions as edges, we obtain 
a much smaller state space than if all the deterministic bytecode instructions had 
been specified as rules, in which case 340 rules would be used. 

4 Formal Analysis 

Using the underlying fair rewriting, search and model checking features of Maude, 
JavaFAN can be used to formally analyze Java programs in bytecode format. The 

4 In our model, but in general various implementations of the JVM use a variety of 
algorithms to choose the thread. By not committing to any specific deterministic 
choice approach, our formal analysis can discover subtle violations that may appear 
in some JVM implementations, but may not show up in others. 
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Maude’s specification of the JVM can be used as an interpreter to simulate fair 
JVM computations by rewriting. Breadth-first search analysis is a semi-decision 
procedure that can be used to explore all the concurrent computations of a pro- 
gram looking for safety violations characterized by a pattern and a condition. 
Infinite state programs can be analyzed this way. For finite state programs it is 
also possible to perform explicit-state model checking of properties specified in 
linear temporal logic (LTL). 

4.1 Simulation 

Our Maude specification provides executable semantics for the JVM, which can 
be used to execute Java programs in bytecode format. This simulator can also be 
used to execute programs with symbolic inputs. Maude’s frewrite command 
provides fair rewriting with respect to objects, and since all Java threads are 
defined as objects in the specification, no thread ever starves, although no spe- 
cific scheduling algorithm is imposed. This assumption of fairness (with respect 
to threads) coincides with real models of JVM with a built-in scheduler, since 
scheduling algorithms also take the fairness into account. This fairness assump- 
tion does not mean that a deadlock is avoided; a deadlock in our model is a 
state in which no more rewrites are possible. The fair rewriting helps us avoid 
the situations in which a thread stuck in a loop is being executed forever, while 
other threads that can also be executed are starving. 

To facilitate user interaction, the JVM semantics specification is integrated 
within the JavaFAN tool, that accepts standard bytecode as its input. The user 
can use javac (or any Java compiler) to generate the bytecode. She can then 
execute the bytecode in JavaFAN, being totally unaware of Maude. We use 
javap as the disassembler on the class files along with another disassembler 
jreversepro [14] to extract the constant pool information that javap does not 
provide. 

4.2 Breadth-First Search 

Using the simulator (Section 4.1), one can explore only one possible trace (mod- 
eled as sequence of rewrites) of the Java program being executed. Maude’s 
search command allows exhaustively exploring all possible traces of a Java pro- 
gram. The breadth-first nature of the search command gives us a semi-decision 
procedure to find errors even in infinite state spaces, being limited only by the 
available memory. Below, we discuss a number of case studies. 

Remote Agent. The Remote Agent (RA) is an Al-based spacecraft controller 
that has been developed at NASA Ames Research Center and has been part 
of the software component of NASA’s Deep Space 1 shuttle. On Tuesday, May 
18th, 1999, Deep Space l’s software deadlocked 96 million kilometers away from 
the Earth and consequently had to be manually interrupted and restarted from 
ground. The blocking was due to a missing critical section in the RA that had led 
to a data-race between two concurrent threads, which further caused a deadlock 
[10,11]. This real life example shows that even quite experienced programmers 
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can miss data-race errors in their programs. Moreover, these errors are so sub- 
tle that they often cannot be exposed by intensive testing procedures, such as 
NASA’s, where more than 80% of a project’s resources go into testing. This 
justifies formal analysis techniques like the ones presented in this paper which 
could have caught that error. 

The RA consists of three components: a Planner that generates plans from 
mission goals; an Executive that executes the plans; and a Recovery system that 
monitors RA’s status. The Executive contains features of a multithreaded oper- 
ating system, and the Planner and Executive exchange messages in an interactive 
manner. Hence, this system is highly vulnerable to multithreading errors. Events 
and tasks are two major components (see [8] for the code) . In order to catch the 
events that occur while tasks are executing, each event has an associated event 
counter that is increased whenever the event is signaled. A task then only calls 
wait_f or_event in case this counter has not changed, hence, there have been no 
events since it was last restarted from a call of wait_f or_event. 

The error in this code results from the unprotected access to the variable 
count of the class Event. When the value of eventl . count is read to check the 
condition, it can change before the related action is taken, and this can lead 
to a possible deadlock. This example has been extensively studied in [10,11]. 
Using the search capability of our system, we also found the deadlock in the 
same faulty copy in 0.3 seconds. This is while the tool in [19] finds it in more 
than 2 seconds in its most optimized version 5 . 

The Thread Game. The Thread Game [18] is a simple multithreaded program 
which shows the possible data races between two threads accessing a common 
variable (see [8] for the code) . Each thread reads the value of the static variable 
c twice and writes the sum of the two values back to c. Note that these two 
readings may or may not coincide. An interesting question is what values can c 
possibly hold during the infinite execution of the program. Theoretically, it can 
be proved that all natural numbers can be reached [18]. 

We can use Maude’s search command to address this question for each specific 
value of N. The search command can find one or all existing solutions (sequences) 
that lead to get the value N. We have tried numbers up to 1000 where for all of 
them a solution is found in a reasonable amount time (Table 1). 

Table 1 . Thread Game Times. 



N 


50 


100 


200 


400 


500 


1000 


Time(s) 


7.2 


17.1 


41.3 


104 


4.5m 


10.1m 



4.3 Model Checking 

Maude’s model checker is explicit state and supports Linear Temporal Logic. 
This general purpose rewriting logic model checker can be directly used on the 

5 All the performance results given in this section are in seconds on a 2.4GHz PC. 
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Maude specification of JVM’s concurrent semantics. This way, we obtain a model 
checking procedure for Java programs for free. The user has to specify in Maude 
the atomic propositions to be used in order to specify relevant LTL properties. 
We illustrate this kind of model checking analysis by the following examples. 

Table 2. Dining Philosophers Times. 



Tests 


Times(s) 


DP(4) 


0.64 


DP(5) 


4.5 


DP(6) 


33.3 


DP(7) 


4.4m 


DP(8) 


13.7m 


DP(9) 


803.2m 


DF(4) 


21.5 


DF(5) 


3.2m 


DF(6) 


23.9m 


DF(7) 


686.4m 



Dining Philosophers. See [8] for the version of the dining philosophers prob- 
lem that we have used in our experiments (DP). The property that we have 
model checked is whether all the philosopher can eventually dine. Each philoso- 
pher prints her ID when she dines. Therefore, to check whether the first philoso- 
pher has dined, we only have to check if 1 is written in the output list (see 
Section 3.1 for the output process). The LTL formula can be built based on 
propositions defined as follows, op Check : Int -> Prop, where Check(N) will 
be true at some state if the output list contains all the numbers from 1 to N. 
In this case, we check the following LTL formula using the modelCheck, where 
InitialState is the initial state of the program defined automatically. The for- 
mula that we model checked is OCheck(n) for n philosophers. The model checker 
generates counterexamples, in this case a sequence of states that lead to a pos- 
sible deadlock. The sequence shows a situation in which each philosopher has 
acquired one fork and is waiting for the other fork. Currently, we can detect the 
deadlock for up to 9 philosophers (Table 2). We also model checked a slightly 
modified version of the same program which avoids deadlock (DF). In this case, 
we can prove the program deadlock- free when there are up to 7 philosophers. 
This compares favorably with JPF [1, 12] which for the same program cannot 
deal with 4 philosophers. 



2- Stage Pipeline implements a pipeline computation (see [8] for the code), 
where each pipeline stage executes as a separate thread. Stages interact through 
connector objects that provide methods for adding and taking data. The prop- 
erty we have model checked for this program is related to the proper shutdown 
of pipelined computation, namely, “the eventual shutdown of a pipeline stage in 
response to a call to stop on the pipeline’s input connector”. The LTL formula 
for the property is □(clstop — > 0(->stagelreturn)). JavaFAN model checks the 
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property and returns true in 17 minutes (no partial order reduction was used). 
This compares favorably with the model checker in [19] which without using the 
partial order reduction performs the task in more than 100 minutes. 



5 Lessons Learned and Future Work 

We have presented JavaFAN, explained its design, its rewriting logic semantic 
basis, and its Maude implementation. We have also illustrated JavaFAN’s for- 
mal analysis capabilities and its performance on several case studies. The main 
lessons learned are that, using a rewriting logic semantics and a high-performance 
logical engine as a basis to build software analysis tools for conventional con- 
current programs has the following advantages: (1) it is cost-effective in terms 
of amount of work needed to develop such tools; (2) it provides a generic tech- 
nology that can bee applied to many different languages and furthermore the 
analysis tools for each language come essentially for free from the underlying log- 
ical engine; and (3) it has competitive performance compared to similar software 
analysis tools tailored to a specific language. 

As always, there is much work ahead. On the one hand, in collaboration 
with Feng Chen support for the Java source code level has also been added 
to to JavaFAN and we plan to gain more experience and further optimize the 
tool at both levels. On the other, we plan to extend the range of formal anal- 
yses supported by JavaFAN, including, among the others, support for program 
abstraction, to model check finite-state abstractions of infinite-state programs, 
and for theorem proving , using Maude’s inductive theorem prover (ITP) [4] as 
a basis. Furthermore, since the general techniques used in JavaFAN are in fact 
language-independent, we hope that other researchers find these techniques use- 
ful and apply them to develop similar tools for other concurrent languages. 
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Abstract. We prove the correctness of a sliding window protocol with 
an arbitrary finite window size n and sequence numbers modulo 2 n. We 
show that the sliding window protocol is branching bisimilar to a queue 
of capacity 2 n. The proof is given entirely on the basis of an axiomatic 
theory, and was checked with the help of PVS. 

1 Introduction 

Sliding window protocols [6] (SWPs) ensure successful transmission of messages 
from a sender to a receiver through a medium, in which messages may get lost. 
Their main characteristic is that the sender does not wait for an incoming ac- 
knowledgement before sending next messages, for optimal use of bandwidth. 
This is the reason why many data communication systems include the SWP, in 
one of its many variations. 

In SWPs, both the sender and the receiver maintain a buffer. In practice the 
buffer at the receiver is often much smaller than at the sender, but here we make 
the simplifying assumption that both buffers can contain up to n messages. By 
providing the messages with sequence numbers, reliable in-order delivery without 
duplications is guaranteed. The sequence numbers can be taken modulo 2 n (and 
not less, see [42] for a nice argument). The messages at the sender are numbered 
from * to i + n (modulo 2n); this is called a window. When an acknowledgement 
reaches the sender, indicating that k messages have arrived correctly, the window 
slides forward, so that the sending buffer can contain messages with sequence 
numbers i+k to i + k + n (modulo 2n). The window of the receiver slides forward 
when the first element in this window is passed on to the environment. 

Within the process algebraic community, SWPs have attracted much atten- 
tion. We provide a comparison with verifications of SWPs in Section 8, and 
restrict here to the context in which the current paper was written. After the 
advent of process algebra in the early 80’s of last century, it was observed that 
simple protocols, such as the alternating bit protocol, could readily be verified. In 
an attempt to show that more difficult protocols could also be dealt with, SWPs 
were considered. Middeldorp [31] and Brunekreef [4] gave specifications in ACP 
[1] and PSF [30], respectively. Vaandrager [43], Groenveld [12], van Wamel [44] 
and Bezem and Groote [3] manually verified one-bit SWPs, in which the windows 
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have size one. Starting in 1990, we attempted to prove the most complex SWP 
from [42] (not taking into account additional features such as duplex message 
passing and piggybacking) correct using the process algebraic language ^CRL 
[16]. This turned out to be unexpectedly hard, which is shown by the 13 year 
it took to finish the current paper, and led to significant developments in the 
realm of process algebraic proof techniques for protocol verification. We therefore 
consider the current paper as a true milestone in process algebraic verification. 

Our first observation was that the external behaviour of the protocol, as 
given in [42], was unclear. We adapted the SWP such that it nicely behaves 
as a queue of capacity 2 n. The second observation was that the SWP of [42] 
contained a deadlock [13, Stelling 7], which could only occur after at least n 
messages were transmitted. This error was communicated to Tanenbaum, and 
has been repaired in more recent editions of [42]. Another bug in the /iCRL 
specification of the SWP was detected by means of a model checking analysis. 
A first attempt to prove the resulting SWP correct led to the verification of a 
bakery protocol [14], and to the development of the cones and foci proof method 
[19,9]. This method rephrases the question whether two system specifications 
are branching bisimilar in terms of proof obligations on relations between data 
objects. It plays an essential role in the proof in the current paper, and has 
been used to prove many other protocols and distributed algorithms correct. 
But the correctness proof required an additional idea, already put forward by 
Schoone [37], to first perform the proof with unbounded sequence numbers, and 
to separately eliminate modulo arithmetic. 

We present a specification in /xCRL of a SWP with buffer size 2 n and win- 
dow size n, for arbitrary n. The medium between the sender and the receiver 
is modelled as a lossy queue of capacity one. We manually prove that the ex- 
ternal behaviour of this protocol is branching bisimilar [10] to a FIFO queue 
of capacity 2 n. This proof is entirely based on the axiomatic theory underlying 
/xCRL and the axioms characterising the data types. It implies both safety and 
liveness of the protocol (the latter under the assumption of fairness). First, we 
linearise the specification, meaning that we get rid of parallel operators. More- 
over, communication actions are stripped from their data parameters. Then we 
eliminate modulo arithmetic, using the proof principle CL-RSP [2] , which states 
that each linear specification has a unique solution (modulo branching bisimu- 
lation). Finally, we apply the cones and foci technique, to prove that the lin- 
ear specification without modulo arithmetic is branching bisimilar to a FIFO 
queue of capacity 2 n. All lemmas for the data types, all invariants and all cor- 
rectness proofs have been checked using PVS. The PVS files are available via 
http : //www . cwi . nl/~badban/swp . html. Ongoing research is to extend the cur- 
rent verification to a setting where the medium is modelled as a lossy queue of 
unbounded capacity, and to include duplex message passing and piggybacking. 

In this extended abstract we omitted most equational definitions of the data 
types, most lemmas regarding these data types, part of the invariants and part 
of the correctness proofs. The reader is referred to the full version of the paper 
[8], for these definitions and proofs. 
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2 /iCRL 

/iCRL [16] (see also [18]) is a language for specifying distributed systems and 
protocols in an algebraic style. It is based on the process algebra ACP [1] ex- 
tended with equational abstract data types [28]. In a /tCRL specification, one 
part specifies the data types, while a second part specifies the process behaviour. 

The data types needed for our /iCRL specification of a SWP are presented 
in Section 3. In this section we focus on the process part of /iCRL. Processes 
are represented by process terms, which describe the order in which the actions 
from a set A may happen. A process term consists of action names and recur- 
sion variables combined by process algebraic operators. Actions and recursion 
variables may carry data parameters. There are two predefined actions outside 
A : 5 represents deadlock, and r a hidden action. These two actions never carry 
data parameters, p-q denotes sequential composition and p+q non-deterministic 
choice. Summation ^2 d . D p(d ) provides the possibly infinite choice over a data 
type D , and the conditional construct p <\ b > q with b a data term of sort Bool 
behaves as p if b and as q if ~A>. Parallel composition p || q interleaves the actions 
of p and q; moreover, actions from p and q may also synchronise to a commu- 
nication action, when this is explicitly allowed by a predefined communication 
function. Two actions can only synchronise if their data parameters are equal. 
Encapsulation du ( p ) , which renames all occurrences in p of actions from the set 
TL into 6, can be used to force actions into communication. Hiding n (p) renames 
all occurrences in p of actions from the set X into r. Finally, processes can be 
specified by means of recursive equations X(d\:D\, . . . , d n :D n ) « p , where X is 
a recursion variable, di a data parameter of type Dj for i = 1 , . . . , n, and p a 
process term (possibly containing recursion variables and the parameters di). A 
recursive specification is linear if it is of the form 

i 

X(d 1 -.D 1 ,...,dn-.D n )^J2 J2 < bi > < 5 . 

i= 1 Zi'.Zi 

To each /iCRL specification belongs a directed graph, called a labelled tran- 
sition system, which is defined by the structural operational semantics of /.iCRL 
(see [16]). In this labelled transition system, the states are process terms, and 
the edges are labelled with parameterised actions. Branching bisimulation ±± b 
[10] and strong bisimulation ±± [33] are two well-established equivalence rela- 
tions on the states in labelled transition systems. Conveniently, strong bisimula- 
tion equivalence implies branching bisimulation equivalence. The proof theory of 
/iCRL from [15] is sound modulo branching bisimulation equivalence, meaning 
that if p « q can be derived from it then p ±± b q. 

The goal of this paper is to prove that the initial state of the forthcoming 
/iCRL specification of a SWP is branching bisimilar to a FIFO queue. We use 
three proof principles from the literature: 

— Sum elimination [14] states that a summation over a data type from which 
only one element can be selected can be removed. 

— CL-RSP [2] states that the solutions of a linear /tCRL specification that does 
not contain any infinite r sequence are all strongly bisimilar. 
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— The cones and foci method from [9, 19] rephrases the question whether two 
linear /iCRL specifications tj(S i) and S 2 are branching bisimilar, where S 2 
does not contain actions from some set X of internal actions, in terms of 
data equalities. A state mapping (j) relates each state in Si to a state in S 2 . 
Furthermore, some states in Si are declared to be focus points , by means of 
a predicate FC. The cone of a focus point consists of the states in Si that 
can reach this focus point by a string of actions from X. It is required that 
each reachable state in Si is in the cone of a focus point. If a number of 
matching criteria are satisfied, then tj(Si) and S 2 are branching bisimilar. 



3 Data Types 

In this section, the data types used in the /iCRL specification of the SWP are pre- 
sented: booleans, natural numbers supplied with modulo arithmetic, and buffers. 

Booleans and Natural Numbers. Bool is the data type of booleans. t and f denote 
true and false, A and V conjunction and disjunction, — » and <-> implication and 
logic equivalence, and -> negation. For a boolean b, we abbreviate b = t to b and 
b = f to - 16 . Unless otherwise stated, data parameters in boolean formulas are 
universally quantified. 

For each data type D in this paper there is an operation if : Bool xDxD — > D 
with as defining equations if( t, d,e) = d and if( f, d , e) = e. Furthermore, for each 
data type D in this paper one can easily define a mapping eq : D x D — > Bool 
such that eq(d,e) holds if and only if d = e can be derived. For notational 
convenience we take the liberty to write d = e instead of eq(d, e). 

Nat is the data type of natural numbers. 0 denotes zero, S(n) the successor of 
n, +, — and • addition, monus (also called proper subtraction) and multiplication, 
and <, <, > and > less-than(-or-equal) and greater-than(-or-equal). Usually, 
the sign for multiplication is omitted, and -1 (i = j) is abbreviated to * / j. 
As binding convention, {=,f=} > {■} > {+,-} > {<,<,>,>} > {-'} > {A,V} > 
L 

Since the buffers at the sender and the receiver in the sliding window are of 
size 2 n, calculations modulo 2 n play an important role. i\ n denotes i modulo n, 
while i div n denotes i integer divided by n. 

Buffers. The sender and the receiver in the SWP both maintain a buffer contain- 
ing the sending and the receiving window, respectively (outside these windows 
both buffers are empty). Let A be the set of data elements that can be commu- 
nicated between sender and receiver. The buffers are modelled as a list of pairs 
(d, i) with d £ A and i € Nat, representing that position (or sequence number) i 
of the buffer is occupied by datum d. The data type Buf is specified as follows, 
where [] denotes the empty buffer: [] :— » Buf and in : A x Nat x Buf — * Buf. 
q\ n denotes buffer q with all sequence numbers taken modulo n. []|„ = [] and 
in(d,i, q)\ n = in{d,i\ n ,q\ n ). test(i,q) produces t if and only if position i in q is 
occupied, retrieve (i, q) produces the datum that resides at position i in buffer q 
(if this position is occupied), and remove{i,q) is obtained by emptying position 
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i in buffer q. release(i,j,q) is obtained by emptying positions i up to j excluded 
in q. release\ n {i,j,q) does the same modulo n: 

release{i,j,q) — if(i>j,q,release(S(i),j,remove(i,q))) 
release\ n (i,j, q) = if(i\n=j\n,q, release\ n {S(i),j, remove(i, q))) 



next- empty (i,q) produces the first empty position in q , counting upwards from 
sequence number i onward. next-empty\ n (i 1 q) does the same modulo n. 



next-empty(i, q) 
next-empty\ n (i, q) 



if(test(i, q), next- empty (S(i), q),i) 

{ next- empty (i\ n ,q\ n ) if next- empty (i\ n , q\ n ) < n 
next-empty(0, q\ n ) otherwise 



Intuitively, in-window(i, j, k ) produces t if and only if j lies in the range from i 
to k — 1, modulo n, where n is greater than i, j and k. 

in-window(i, j, k) = i<j<kVk<i<jWj<k<i 



Lists. The data type List of lists is used in the specification of the desired 
external behaviour of the SWP: a FIFO queue of capacity 2 n. It is specified 
by the empty list () > List and in : A x List —* List. length(X) denotes the 

length of A, top( A) produces the datum at the top of A, tail(X) is obtained by 
removing the top position in A, append(d , A) adds datum d at the end of A, and 
A-H-A' represents list concatenation. Furthermore, q[i..j) is the list containing the 
elements in buffer q at positions i up to but not including j. An empty position 
in q , in between i and j, gives rise to an occurrence of the default datum do in 
q[i..j). 

( 0 if i > j 

q[i..j ) = < in(retrieve(i,q),q[S(i)..j }) if i < j A test(i,q) 

[ in(do, q[S(i)..j}) if i < j A -> test{i , q) 



4 Sliding Window Protocol 

In this section, a /xCRL specification of a SWP is presented, together with its 
desired external behaviour. 

Specification of a Sliding Window Protocol. A sender S stores data elements 
that it receives via channel A in a buffer of size 2 n, in the order in which they 
are received. S can send a datum, together with its sequence number in the 
buffer, to a receiver R via a medium that behaves as lossy queue of capacity 
one, represented by the medium K and the channels B and C. Upon reception, 
R may store the datum in its buffer, where its position in the buffer is dictated 
by the attached sequence number. In order to avoid a possible overlap between 
the sequence numbers of different data elements in the buffers of S and R, no 
more than one half of the buffers of S and R may be occupied at any time; these 
halves are called the sending and the receiving window, respectively. R can pass 
on a datum that resides at the first position in its window via channel D; in 
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that case the receiving window slides forward by one position. Furthermore, R 
can send the sequence number of the first empty position in (or just outside) its 
window as an acknowledgement to S via a medium that behaves as lossy queue 
of capacity one, represented by the medium L and the channels E and F. If S 
receives this acknowledgement, its window slides accordingly. 




The sender S is modelled by the process S(^, to, q), where q is a buffer of size 
2 n, l the first position in the sending window, and m the first empty position in 
(or just outside) the sending window. Data elements can be selected at random 
for transmission from (the filled part of) the sending window. 

S (£:Nat, m:Nat, q:Buf) 

~ E± ^ r A(d)-S(f , S(m)| 2n , in(ii, m, g)) < in-window(£,m, (£ + n ) | 2n ) > S 
+ J2k Nat SB{retrieve(k, q), k)-S(i, m, q) < test(k,q) > <5 
+ J^k-.Nat rF(k)-S(k, m, release \ 2n {£ , k, q)) 

The receiver R is modelled by the process R (£',q'), where q' is a buffer of size 
2 n and the first position in the receiving window. 

R (e':Nat,q':Buf) 

~ I] ^ ^:4I]fe:A^at r c( rf I fc )■( R ■( ^ ^* n ( d l fc .9 , )) < in-window {£' , k, {£' + n ) | 2n ) > R(^',g')) 
+ sn(retrieve(l' ,q'))-Tl(S(£')\ 2 n,remove(l' ,q')) < test(£',q') > <5 
+ SE(next-empty\ 2 n{£' ,q'))-K (£' , q') 

For i £ {B,C,E,F}, Sj and r\ can communicate, resulting in c,. 

Finally, the mediums K and L, which have capacity one, may lose frames 
between S and R. The action j indicates an internal choice. 

K ~ J2 d[ AJ2k:Nat r B(d,k)ij-S C {d,k) + j)-K 

L ~ Efc:iV a t r E(fe)-0'-SF(fe) + j)-L 



The initial state of the SWP is expressed by tj(9-h(S( 0, 0, []) || R(0, []) || 
K || L)), where the set H consists of the read and send actions over the internal 
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channels B, C, E, and F, while the set X consists of the communication actions 
over these internal channels together with j . 

External Behaviour. Data elements that are read from channel A by S should be 
sent into channel D by R in the same order, and no data elements should be lost. 
In other words, the SWP is intended to be a solution for the linear specification 

Z(A -.List) ~ '}2 d . A rA(d) Z(append(d,\)) < length(X) < 2n t> 5 
+ sn{top(\))-Z(tail(\)) < length(X) > 0 t> 8 

Note that rx{d) can be performed until the list A contains 2 n elements, because 
in that situation the sending and receiving windows will be filled. Furthermore, 
sr>(top(A)) can only be performed if A is not empty. 

The remainder of this paper is devoted to proving the following theorem. 

Theorem 1. rz(d n (S(0, 0, []) || R(0, []) || K || L)) ±± b Z«». 

5 Transformations of the Specification 

The starting point of our correctness proof is a linear specification N mo d, in 
which no parallel operators occur. N mo d can be obtained from the /iCRL spec- 
ification of the SWP without the hiding operator, by means of a linearisa- 
tion algorithm presented in [17]. N mo( ; contains five extra parameters: e:D and 
g,g' ,h,h' :Nat. Intuitively, g (resp. g') equals zero when medium K (resp. L) is 
inactive, equals one when K (resp. L) just received a datum, and equals two if 
K (resp. L) decides to pass on this datum. Furthermore, e (resp. h) equals the 
datum that is being sent from S to R (resp. the position of this datum in the 
sending window) while j / 0, and equals the dummy value do (resp. 0) while 
g = 0. Finally h! equals the first empty position in the receiving window while 
g' 0 and equals 0 while g' = 0. Furthermore, data arguments are stripped from 
communication actions, and these actions are renamed to a fresh action c. For 
the sake of presentation, we only present parameters whose values are changed. 

N mo( f (X Nat, m:Nat, q:Buf ,£' :Nat, q':Buf, g:Nat, e\D, h:Nat, g':Nat, h':Nat) 

~ J2 d: A rA (d)-Nmod{m:=S(m)\2n,q'.=in(d,m,q)) < in-window(£,m, (£ + n)\2n) > 8 
+ J2k-.Nat C 'N ™od.(g~l, e '.=retrieve(k, q) , h:=k) < test(k,q) A g = 0 t> 8 
+ j-N mo d(g:=0,e-.=d 0 ,h.=0) < g = 1 > 5 
+ J-N mod (g:=2) < g m 1 > 6 

+ c-N mo d(q':=in(e, h, q'),g:= 0, e:=do, h:= 0) < in-window (£' , h, (£' + n)| 2 n) 

Ag = 2 t> 5 

+ c-N mo d((/:=0, e:=do, h:=0) < -<in-window(l' , h, (£' + n)| 2 «) A g = 2 > <5 
+ sr>(retrieve(£',q'))-T>l m od{£''=S(£')\ 2 n,q''.=remove(£',q')) < test(£',q') > 5 
+ c-N mo d(g'~~L,ti:= next- empty \ 2 n(£',q’)) < g' = 0 t> 8 
+ i-N mod (gr':=0, /i'jssO) < g' = 1 > 8 
+ i-N m0 d(gr':=2) < g' = 1 > 8 

+ c-N mo d(£~h',q:=release\2n(£,h',q),g':=0,h':=0) c g' = 2 t> 8 
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Theorem 2. 

ri(S w (S(0,0,Q) || R(0, D) || K || L)) ±± T {c , j} (N mod (0, 0, [], 0, [], 0, d 0 , 0, 0, 0)). 

The specification of N non mod is obtained by eliminating all occurrences of 
\- 2 n from N mo d, and replacing in-window{£, to, [£ + n)\ 2 n by m < £ + n and 
in-window{£' , h, (£' + n)\ 2 n by £' < h < £' + n. 

Theorem 3. N mo( j(0, 0, [], 0, [],0,d o , 0, 0, 0) ±± N nonm od{0, 0, [], 0, [], 0, d o ,0, 0, 0). 

The proof of Theorem 2 , using a linearisation algorithm [ 17 ] and a simple 
renaming, is omitted. The proof of Theorem 3 is shown in Section 7 . 1 . 



6 Properties of Data and Invariants of N non mod 

Lemma 1 collects results on modulo arithmetic related to buffers. Simpler lem- 
mas on modulo arithmetic, buffers, the next- empty operation, and lists can be 
found in the full version of this paper [8]. We use those lemmas without mention. 

Lemma 1. The lemmas below hold for modulo arithmetic related to buffers. 

1. \/j:Nat(test(j, q) — > * < j <i + n)Ai<k<i + n^> test(k, q ) = test(k | 2 n, <?| 2 n) 

2. Vj:Nat(test(j, q) — > i < j < i + n) A test(k, q) — * retrievefk, q) = retrieve(k\ 2 n , q\ 2 n) 

3. i < k < i + n — > in-windowfi | 2 n, k\ 2 n, (i + n)| 2 n) 

4- in-window(i\ 2 n , k | 2 n, (* + n) | 2 n) — ♦ k + n < iV i < k < i + n V k > i + 2n 
5. Vj:Nat(test(j, g) — > » < j < i + n) A test(k, q\ 2 n) — > in-window(i\ 2 n , k, ( i + n)| 2 n) 

Invariants of a system are properties of data that are satisfied throughout the 
reachable state space of the system. Lemma 2 collects 9 invariants of N non mod 
that are needed in the correctness proofs in the current paper. 

Lemma 2. The invariants below hold for N nonmo d(£,m, q,£' , q ' , g, e, h, g' ,h'). 

1. max{h' ,£}< next- empty (£' ,q') 

2. g ^ 0 — > h < m 

3. next- empty (£', q') < min {m,£' + n} 

4 ■ test(i, q) <-> l < i < m 

5. £<m<£ + n<£' + 2n 

6. g ^ 0 — > next- empty (£' , q') < h + n 

7. j^OA testfh, q) — * retrieve(h, q) = e 

8. g ^ 0 A testfh, q') — > retrieve(h, q') = e 

9. £ < i A j < next-empty{i,q') — * q[i..j) = q'[i-.j) 



7 Correctness of N mo ^ 

7.1 Equality of N mod and N nonraod 

In this section we present a proof of Theorem 3 . It suffices to prove that for all 
£, m, £' , h, h! : Nat, q, q ' : Buf, e : A and g, g 1 < 2 , 

-N"mod (f 1 2n 5 TO 1 2 n 1 q\ 2n 5 £ | 2 n 5 q | 2 n 1 9 i h\ 2 n > 9 , h [2 n) 

^ ^ ^ nonmod (f 1 2n 5 AU 1 2n , q\ 2 n 5 £ | 2 n 5 q | 2 n , 9 i ^ 1 2n 5 9 1 ^ 1 2 n) 
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Proof. We show that N mo d(^ 2 n, m\ 2n , q\ 2n , V\im q'\ 2 n, g, e, h\ 2n , g', h'\ 2n ) is a solution 
for the defining equation of N nonmo d(£, m, q, (! , q' , g, e, h, g' , h'). Hence, we must derive 
the following equation. 



m|2n, Q|2 ?x, £ |2n,Q | 2n , <7, 6, h\ 2 n , g \ 2 n) 

~J 2 d:A r ^( d )'^rnod(m:=S(m)\ 2 n ,q-.=in(d,m,q)\ 2 n)< m < £ + n t> 8 (A) 

+ J2k-.Nat c '^ mod (9-=^,e:=retrieve(k,q),h:=k\2n) < test(k, q) A g = 0 > S (B) 
+ j N mo d(g:=0,e:=do,h:=0) < g = 1 > 8 (G) 

+ j'N™w(j:=2) < g = 1 > 6 (D) 

+ c-N m0 d(g':=m(e, h, q')\ 2 „, g~0, e:=d 0 , h:= 0) c t'<h<£' + nAg = 2>5 ( E ) 

+ c-N mo rf((?:=0, e:=do, h:= 0) < ->{£' <h<£' + n)Ag = 2>8 ( F ) 

+ SD(refne^e(^ , ,( 7 , ))-N morf (£ , :=S'(£ , )| 2 n,i 5 , ':=remo?;e(^',( 5 r')| 2 n) < test(£’,q') > <5 (G) 
+ c-N mo d(ff':=l, h':=next-empty(£' ,q')\ 2 n) < g' = 0 > <5 (H) 

+ j N mod (g':=0, h':=0) < g' = 1 > <5 (!) 

+ j-N mod ( ff ':=2) o g' = 1x5 (J) 

+ c-N mo rf(^:=h'|2„,<7:=rdeose(£, h', q)| 2 n, s':=0, ti:=0) < = 2 > <5 (A') 



In order to prove this, we instantiate the parameters in the defining equation of 

■Nmod with £\ 2 n , m| 2n , q\ 2n , £ |2n, *?, C, /l|2n, 5 1 ,h |27i- 

■N mo ^ (f) 2n , U2 1 2n , 2n , ^ |2n,9 1 2 n , P, e, h | 2n , P , A |2n) 

« r , A(d)-N m0 d(m:=S , (m|2n)|2n, q\=in(d , ra| 2n , ?|2n)) 

<1 OT-wmdow(£|2n,m|2n,(^|2n +n)|2n) > <5 
+ J 2 k:Nat c-N mo< i(g : =l, e:=retrieve(k, q\ 2 n), h:=k) < test(k, q\ 2n ) A 3 = 0 > <5 
+ j-N mo d(g~0, e:=d o ,h:= 0 ) < g = 1 t> 8 
+ ;j-^mod(g.= 2 ) < g = 1 > 8 

+ c-N mo d(q' :=in(e, h| 2 n, g'| 2 n), fl:=0, e:=do, h:= 0) 

<1 in-window(£'\ 2n , h| 2 n, (^'Iz™ + n)|2n) A 3 = 2 > <5 
+ c-N moli (ff:=0, e:=do, h:= 0) 

<1 -^in-window(£'\ 2n , h\ 2n , (£'\2n + n)\2n) A g = 2 t> 8 
+ sv(retrieve(£'\2n, q'Un))^ mo d(£'~S(£'\2n)\2n, q' ■■=remove(£'\2n, q'\ 2 n)) 

< test(£'|2n, g'hn) > 5 

+ c-N TOO(i (0':=l,/i , :=ne:Ef-emptt/|2n(^ , |2n,<2 ,, |2n)) < ff' = 0 > 8 
+ j-N mo( j(</:=0, h':= 0 ) < g' = 1 > 8 
+ J'N mM j(</:=2) < g' = 1 > 8 

+ c-N 7no d(£:=ti\2n,q:=release\2n(£\2n,h'\2n,q\2n),g'~0,ti:=0) <1 g' = 2 t> 8 

To equate the eleven summands in both specifications, we obtain a number of proof 
obligations. Here, we focus on summands A, B, and E. 

A m < £ + n = in-window(£\ 2 n ,m\ 2n , (£\ 2n + ri)\ 2n ). 

m<£ + nr->£<m< £ + n (Inv. 2.5) — > in- window(£ \ 2n , m\ 2n , {£ + n)\ 2n ) 
(Lem. 1.3). Reversely, in-window{£\ 2ni fnj 2n , (£ + n)| 2 n) — > m+n < £\/£ < m < £+ 
nV m > £+2 n (Lem. 1.4) <-> m < £+n (Inv. 2.5). Since (£ + n)\ 2 n = {£\ 2 n + n) \ 2n , 
we have m < £ + n = in-window(£\ 2n ,m\ 2n ,{£\ 2 n +n)| 2 «). 
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B Below we equate the entire summand B of the two specifications. The conjunc- 
tion g = 0 and the argument g: — 1 of summand B are omitted, because they are 
irrelevant for this derivation. 

By Inv. 2.4 and 2.5, test(j, q) — > £ < j < £ + n. So by Lem. 1.5, test(k ' , q | 2 n) implies 
in-window(£\ 2 n,k' , (£ + n)\ 2 n ). test(k' , g| 2 n) implies k' = fc'^n, and by Lem. 1.4, 
k' + n < £\ 2 n V £\ 2 n < k' < l\ 2 n + n V k' > £ + 2 n. k' = fe'^n < 2 n implies 
fc' + n < t\ 2 n V £| 2 n < k! < i\ 2 n + U. 

E k-.Nat c-N mod (e:=retrieve(k, q ), h:=k\ 2n ) 

< test(k, q) t> S 

~ Yk-.Nat c-N mod (e:=retrieve(k, q), h:=k\2n) 

<l test(k , q)A^<fc<£-|-n>(5 (Inv. 2.4, 2.5) 

« Yk-.Nat c-N mod (e:=retrieve(k\2n, q\2n), h:=k\ 2 n) 

< test(k\ 2 n, q\ 2 n) A £<k<£+n> S (Lem. 1.1, 1.2) 

« E k ■.NatYk:Nat C ’ ]S! ^°d( e: = retrieVe ( k ' ’ iM , h:=k') 

< test(k ' , q| 2 n) A£<k<£ + nAk' = fc| 2 n > <5 (sum elimination) 

« Efc :N atE i; :iVat C - N ™o<i( e: = reir * e?;e ( fc, >9|2r l ),fe: = fc') 

<: test(k ' , q| 2 n) A k = (£ div 2n)2n + k' A t\ 2 n < k 1 < £\ 2 n + n A k 1 = k\ 2 n > <5 

+ E k ■.NatYk:Nat c - N ™od(e:=retrieve(k',q\2n),h:=k') 

< test(k', q \ 2 n ) A k = S(£ div 2n)2n + k' A k' + n < £j 2 n A k' = k^n > d 
« Efc . Na^ c•N mo( ^(e:=retnene(fc',(2|2«),h:=A: , ) 

< test(k', q \ 2 n ) A £| 2 n < k! < f | 2 ™ + n Ak' — k' >5 
+ Efc : jvat c / N mo d(e:=retrieve(k' , q\ 2 n), h:=k') 

<3 test(k ' , q| 2 n) A fc' + n < f | 2 n A k' = k! > <5 (sum elimination) 

« Efc : jvo* 

<i test(k' , q\ 2 n) > <5 (see above) 

.E g = 2^>l'<h<£'+n — in-window(£' | 2 n, (•£' + n)| 2 «). 

Let g = 2. We have £' < next-empty{f! ,q'), and by Inv. 2.6 together with g = 2, 
next- empty (£', q') < ft + n, so £! < h + n. Furthermore, by Inv. 2.2 together with 
g = 2, h < m, by Inv. 2.5, m < £' + 2 n. Hence, h < £' + 2 n. So using Lem. 1.3 and 
1.4, it follows that £' < h < £' + n = in-window(£' | 2 «, h| 2 n, (£' + n) | 2n ) • 

Equality of other summands can be derived without much difficulty. Hence, we prove 
that Nmod{£\ 2 n,m\ 2 n,q\ 2 n,£'\ 2 n,q'\ 2 n,g,e,h\ 2 n,g',h'\ 2 n) is a solution for the specihca- 
tion of N n0 nmod{£,m,q,£' ,q' , g,e,h, g 1 ,h'). By CL-RSP, they are strongly bisimilar. 

7.2 Correctness of N nonmod 

We prove that N nonmod, is branching bisimilar to the FIFO queue Z of capacity 
2 n (see Section 4), using the cones and foci method [9]. 

Let E abbreviate Nat x Nat x Buf x Nat x Buf x Nat x Ax Nat x Nat x Nat. 
Furthermore, let £:E denote (£,m,q,£',q',g,e,h,g',h'). The state mapping <f> : 
E — * List, which maps states of N nonmod, to states of Z, is defined by: 

4>{0 = q [£'■■ next- empty (£' ,q))-\+q[next- empty (£' ,q)..m) 

Intuitively, </> collects the data elements in the sending and receiving windows, 
starting at the first position of the receiving window (i.e. , £') until the first empty 
position in this window, and then continuing in the sending window until the 
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first empty position in that window (i.e. , m). Note that <j> is independent of 
e, g, £, h, g', h'\ we therefore write q, £', q'). 

The focus points are those states where either the sending window is empty 
(meaning that £ = m), or the receiving window is full and all data elements in 
the receiving window have been acknowledged, meaning that £ = £' + n. That 
is, the focus condition for N n onmod(£, m, q, £', q ' , g, e, h, g', h') is 

FG(£,m,q,£' ,q ,g,e,h,g' ,h!) := £ = mV t = £' + n 

Lemma 3. For each £:2 where the invariants in Lemma 2 hold, there is a £,:2 with 
FC(£) SUCh that Nkonmod (f) * ' * * ? Nkoromod (£, ) , where Cl, . . . , Cf, G F . 

Proof. In case j ^ 0 in £, by summands C, E and F, we can perform one or two commu- 
nication actions to a state where g = 0. By Inv. 2.3, next- empty (l 1 , q 1 ) < min{m, £'+nj. 
We prove by induction on min{m, £' -\ -n} — next- empty (£' , q ) that for each state where 
g = 0 and the invariants in Lemma 2 hold, a focus point can be reached. 

Base Case: next- empty {£' ,q') = min {m,t! + n}. 

In case g' ^ 0 in by summands / and K, we can perform communication actions 
to a state where g' = 0 and next- empty {£! = min {m,£' + n}. By summands H, 

J and K we can perform three communication actions to a state £ where l = h' = 
next- empty (£' , q) = min{m, £' + n}. Then i — m or l = £' + n, so FC(f). 

Induction Case: next- empty {£' ,q') < min{m, £! + n}. 

By Inv. 2.1, £ < next- empty {£' , q ') < m. By Inv. 2.4, test(next- empty {£' , q 1 ), q). Further- 
more, £! < next-empty(£, q') < £' + n. Hence, by summands B, D and E from (f we can 
perform three communication actions to a state . In g := 0, and in comparison to 
, m and f! remain the same, while q := in(d, next- empty (£' ,q'),q) where d denotes 
retrieve{next- empty {£' , q 1 ), q). Since next- empty (£' , in(d, next- empty (£' , q'), q')) 

= next- empty {S {next- empty {£' ,q')),q') > next- empty {£' ,q'), we can apply the induc- 
tion hypothesis to conclude that from a focus point can be reached. 

Theorem 4. For all e:A, T{ c j}(N nonmod (0, 0, [], 0, [], 0, e, 0, 0, 0)) ±± b Z(()). 

Proof. By the cones and foci method we obtain the following matching criteria (cf. 
[9]). Trivial matching criteria are left out. 

’Ll: l'<h<l'-\-n/\g = 2 — > <f>{m,q,t',q') = (j>{m,q,l',in{e,h,q')) 

I. 2: g' = 2 — > q,£' ,q') = <j>{m, release(£,h' ,q ),£' , q’) 

II. 1 : m < £ + n — > length{(f>{m,q,£' ,q')) < 2n 

11.2 : test{£',q') — > length{<j>{m,q,£' ,q')) > 0 

< III. 1 : (f = mV< = <' + «) A length{4>{m, q, £', q')) <2 n — > m < £ + n 

111. 2 : {£ = m V £ = £' + n) A length{(j>{m, q, £', q')) > 0 — > test {£' , q') 

IV: test{£' ,q') — > retrieve{£' ,q') = top(4>{m, q, £' ,q')) 

V.l : m < £ + n —> <f>(S(m),in(d,m,q),£' ,q') = append(d,<j>(m,q,£' ,q')) 

_ V.2 : test{£' ,q') — > (p{m,q, S{£'),remove{£' ,q')) = tail{(j>{m,q,l' ,q')) 

1.1 £'<h<£'+n/\g = 2^> <j>{m, q,£', q') = 4>{m, q, £' , in{e , h , q')). 

Case 1: ft ^ next- empty {£' ,q')). 

Let g = 2. Since next- empty {£' ,in{e,h,q')) = next-empty{£' ,q'), it follows that 
c j>{m , g,^, m(e, ft, g')) = in(e, ft, g')[£' ..next- empty {£' , g')}-H-g[nea;t-err^p^I/(^ , , q')..m). 
Case 1.1: £! < ft < next- empty {£' ,q')). 

test(h,q'), so by Inv. 2.8 together with g = 2, retrieve(h, q') = e. Hence, 
m(e,ft, g')[£' ..next- empty {£' ,g')} = q'[£' ..next- empty {£' ,q')). 
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Case 1.2: -<(£' < h < next- empty (£! 

in(e, h, q')[£' ..next- empty (£', q 1 )) = q'[£' ..next- empty (£' ,q')). 

Case 2: h = next- empty (£! , q'). 

Let g = 2. The derivation splits into two parts. 

(1) in(e, h, q')[£'..h)= q'[£'..h). 

(2) By Inv. 2.1, £ < h, and by Inv. 2.2 together with g = 2, h < m. Thus, by Inv. 
2.4, test(h,q). So by Inv. 2.7 together with g = 2, retrieve(h,q) = e. Hence, 

in(e, h, q' )[h.. next- empty (S(h),q')) 

= in(e, in(e, h, q')[S(h)..next-empty(S(h), q')}) 

= in(e, q'[S(h).. next- empty (S(h),q'))) 

= in(e,q[S(h)..next-empty(S(h),q')}) (Inv. 2.9) 

= q[h... next- empty (S(h),q')) 

Finally, we combine (1) and (2). We recall that h = next-empty(£' ,q'). 

in(e, h, q')[£' ..next- empty (£' , in(e, h, q'))) 

44- q[next- empty (£' , m(e, h, q))..m ) 

= in(e, h, q')[£' ..next-empty(S(h),q')) 

+\-q[next-empty(S(h), q')..m) 

= ( in(e , h, q')[£' ■ .h)+\-in(e, h, q' )[h.. next- empty (S(h),q'))) 

- \+q[next- empty {S{h ), q')..m) 

= q'{£' ..h)-\+q{h.. next- empty {S(h), q ' )) 

-H -q[next-empty(S(h), q')..m) (1), (2) 

= q'{£' ..h)-\+q{h..m) 

1.2 g' = 2 — > q,£', q') = release(£, h' , q),£' , q 1 ). 

By Inv. 2.1, h 1 < next-empty{£\q'). 

So release(£, h ! , q) [next- empty (£' , q') ..m) = q' [next- empty {£' ,q')..m). 

II. 1 m < £ + n — > length((j){rn,q,£' ,q')) < 2 n. 

Let m < £ + n. By Inv. 2.3, next- empty (£' , q') < £' + n. Hence, 

length{q'[£' ..next- empty {£' , q' ))+\-q[nexi- empty (£' , q')..m)) 

= length(q'[£' ..next- empty (£', q 1 ))) + length(q[next-empty{£\q')..m))) 

= {next- empty {£' , q ') — £') + (m — next- empty {£' , q')) 

< n + ( m — £) (Inv. 2.1) 

< 2 n 

II. 2 test{£',q') — > length(<p(m,q,£' ,q')) > 0. 

test{£',q') yields next- empty {£' ,q') = next- empty (S(£'),q') > S{£'). Hence, 
length{(p{m, q, £! , q')) = (next- empty (£', q') — £') + (m — next- empty (£', q ')) > 0. 

III. 1 {£ = m V £ = £' + n) A length(rj)(m , q ,£' , g')) <2 n —> m < £ + n. 

Case 1: £ = m. 

Then m < £ + n holds trivially. 

Case 2: £ = £' + n. 

By Inv. 2.3, next- empty (£', q') < £' + n. Hence, 
length(4>(m, q, £' , q')) 

= (next- empty (£' , q') — £') + ( m — next- empty (£' , q')) 

< ((£' + n) — £') + (m — £) (Inv. 2.1) 

= n + (m — £) 

So length(<j>(m, q, £! , q')) < 2 n implies m < £ + n. 
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III. 2 (< = mV< = I' + n) A length(<f>(m,q,£' ,q')) > 0 — > test(£',q'). 

Case 1: £ = m. 

Since m — next- empty {£! , q') < (m — .£) (Inv. 2.1) = 0, we have 
length (m, q, £', q 1 )) = next- empty (£', q 1 ) — f . 

Hence, length(4>(m, q, £' , g')) > 0 yields next- empty (l' , q 1 ) > £' , which implies 
test(f , g'). 

Case 2: C*= V + n. 

Then by Inv. 2.1, next- empty (£', q') > £' + n, which implies test(£',q'). 

IV test{f! ,q') — > retrieve(£' ,q’) = top(4>(m,q,£' ,q’)). 
test(£',q') implies next- empty (£', q') = next- empty (S(£'),q') > S(£'). 

So q'[£' ..next- empty (£! ,q')} = in(retrieve(£' ,q'),q'[S(£')..next-empty(£' ,q'))). 
Hence, top(<p(m, q, £' , q')) = retrieve(£' ,q'). 

V.l m < £ + n — > 4>{S(m), in(d, m, q),£', q') = append(d, cp(m, q,£', q 1 )). 

q' [£' ..next- empty {£' , q'))-\+in(d, m, q)[next- empty (£' , q')..S{m )) 

= q' [£' ..next- empty (£' , g'))+f append(d, q[next- empty (£' , q')..m)) 

= appended, q' [£' ..next- empty {£' , q' ))-\+q[next- empty (£' , q')..m)) 

V.2 test(£' ,q) — > <p(m,q, S(£'),remove(£' ,q')) = tail(4>(m, q, £' ,q'))- 
test(£',q') implies next- empty (£', q') = next-empty(S(£'),q'). Hence, 

remove (£' , q' )[S (£').. next- empty(S(£'), remove (£' , g'))) 
4+-g[nea:^-emp^?/(S'(£ , ), remove (£' , g'))..m) 

= remove (£’ , q' )[S (£').. next- empty(S(£'), q'))+\-q[next-empty(S(£'),q')..m) 
= remove(£' , q' )[S (£').. next- emp ty (£' , q' ))+\-q[next- empty (£' , g')..m) 

= q [S (£').. next- empty (£' , q ))+\-q[next- empty (£' , q)..m ) 

— tail(q'[£' ..next- empty (£' , q' ))-\+q[next- empty (£' , q')..m )) 



7.3 Correctness of the Sliding Window Protocol 

Finally, we can prove Theorem 1. 

Proof. 

rx(S w (S(0,0,D) II R(0,D) || K II L)) 

±± T{ c j}(N moc j(0,0, 0,0, [],0, do, 0,0,0)) (Thm. 2) 
±1 r {cJ }(N nonmod (0,0, [],0, [],0, do, 0,0,0)) (Thm. 3) 
±± 6 Z«» (Thm. 4) 



8 Related Work 

Sliding window protocols have attracted considerable interest from the formal 
verification community. In this section we present an overview. Many of these 
verifications deal with unbounded sequence numbers, in which case modulo arith- 
metic is avoided, or with a fixed finite window size. The papers that do treat 
arbitrary finite window sizes mostly restrict to safety properties. 

Infinite window size. Stenning [41] studied a SWP with unbounded sequence 
numbers and an infinite window size, in which messages can be lost, duplicated 
or reordered. A timeout mechanism is used to trigger retransmission. Stenning 
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gave informal manual proofs of some safety properties. Knuth [26] examined more 
general principles behind Stenning’s protocol, and manually verified some safety 
properties. Hailpern [20] used temporal logic to formulate safety and liveness 
properties for Stenning’s protocol, and established their validity by informal 
reasoning. Jonsson [23] also verified both safety and liveness properties of the 
protocol, using temporal logic and a manual compositional verification technique. 



Fixed finite window size. Richier et al. [34] specified a SWP in a process algebra 
based language Estelle/R, and verified safety properties for window size up to 
eight using the model checker Xesar. Madelaine and Vergamini [29] specified 
a SWP in Lotos, with the help of the simulation environment Lite, and proved 
some safety properties for window size six. Holzmann [21, 22] used the Spin model 
checker to verify both safety and liveness properties of a SWP with sequence 
numbers up to five. Kaivola [25] verified safety and liveness properties using 
model checking for a SWP with window size up to seven. Godefroid and Long 
[11] specified a full duplex SWP in a guarded command language, and verified the 
protocol for window size two using a model checker based on Queue BDDs. Stahl 
et al. [40] used a combination of abstraction, data independence, compositional 
reasoning and model checking to verify safety and liveness properties for a SWP 
with window size up to sixteen. The protocol was specified in Promela, the input 
language for the Spin model checker. Smith and Klarlund [38] specified a SWP 
in the high-level language IOA, and used the theorem prover MONA to verify 
a safety property for unbounded sequence numbers with window size up to 256. 
Latvala [27] modeled a SWP using Colored Petri nets. A liveness property was 
model checked with fairness constraints for window size up to eleven. 



Arbitrary finite window size. Cardell-Oliver [5] specified a SWP using higher or- 
der logic, and manually proved and mechanically checked safety properties using 
HOL. (Van de Snepscheut [39] noted that what Cardell-Oliver claims to be a live- 
ness property is in fact a safety property.) Schoone [37] manually proved safety 
properties for several SWPs using assertional verification. Van de Snepscheut 
[39] gave a correctness proof of a SWP as a sequence of correctness preserving 
transformations of a sequential program. Paliwoda and Sanders [32] specified 
a reduced version of what they call a SWP (but which is in fact very similar 
to the bakery protocol from [14]) in the process algebra CSP, and verified a 
safety property modulo trace semantics. Rbckl and Esparza [35] verified the cor- 
rectness of this bakery protocol modulo weak bisimulation using Isabelle/HOL, 
by explicitly checking a bisimulation relation. Jonsson and Nilsson [24] used an 
automated reachability analysis to verify safety properties for a SWP with ar- 
bitrary sending window size and receiving window size one. Rusu [36] used the 
theorem prover PVS to verify both safety and liveness properties for a SWP with 
unbounded sequence numbers. Chkliaev et al. [7] used a timed state machine in 
PVS to specify a SWP in which messages can be lost, duplicated or reordered, 
and proved some safety properties with the mechanical support of PVS. 
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Abstract. Data-flow analysis to identify “dead” variables and reset 
them to an “undefined” value is an effective technique for fighting state 
explosion in the enumerative verification of concurrent systems. Although 
this technique is well-adapted to imperative languages, it is not directly 
applicable to value-passing process algebras, in which variables cannot be 
reset explicitly due to the single-assignment constraints of the functional 
programming style. This paper addresses this problem by performing 
data-flow analysis on an intermediate model (Petri nets extended with 
state variables) into which process algebra specifications can be trans- 
lated automatically. It also addresses important issues, such as avoiding 
the introduction of useless reset operations and handling shared read- 
only variables that children processes inherit from their parents. 



1 Introduction 

We consider the verification of concurrent systems using enumerative (or explicit 
state) techniques, which consist in enumerating all the system states reachable 
from the initial state. 

Among the various approaches to avoid state explosion, it has been known 
for long (e.g. [11]) that a significant reduction of the state space can be achieved 
by resetting state variables as soon as their values are no longer needed. This 
avoids to distinguish between states that only differ by the values of so-called 
dead variables , i.e. , variables that will no longer be used in the future before they 
are assigned again. Resetting these variables, as soon as they become useless, to 
some “undefined” value (usually, a pattern of 0-bits) allows states that would 
otherwise differ to be considered as identical. 

When concurrent systems are described using an imperative language with 
explicit assignments, it is possible to reset variables by inserting zero-assignments 
manually in the source program (e.g. [11]). Some languages even provide a dedi- 
cated instruction for resetting variables (e.g. [14, §6]). Despite its apparent sim- 
plicity, this approach proves to be tedious and error-prone, and it obscures the 
source program with verification artefacts. Both its correctness and efficiency 
critically depend on the specifier’s skills (resets have to be inserted at all the 
right places and only these). 
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Moreover, this approach does not apply to value-passing process algebras 
(i.e., process algebras with data values such as Ccs, Csp, Lotos [13], ^Crl, 
etc.), which use a functional programming style in which variables are initialised 
only once and cannot be reassigned (thus, reset) later. 

This paper addresses these two problems by presenting a general method, 
which is applicable to process algebras and which allows variables to be reset 
automatically, in a fully transparent way for the specifier. This method proceeds 
in two steps. 

In a first step, process algebra specifications are translated automatically 
into an intermediate model with an imperative semantics. This approach was 
first proposed in [8, 10], which proposed a so-called network model consisting of 
a Petri net extended with state variables, the values of which are consulted and 
modified when the transitions are executed. This network model is used in the 
CvESAR compiler for Lotos (CjESAR is distributed as part of the widespread 
Cadp verification toolbox [9]). This paper presents the most recent version of 
the network model, which adds to the model of [8, 10] the enhancements intro- 
duced since 1990 in order to allow state space reductions based on transition 
compaction and to support the Exec/C^SAR framework for rapid prototyp- 
ing of Lotos specifications. We believe that this network model is sufficiently 
general to be used for other process algebras than Lotos. 

In a second step, resets are introduced, not at the source level (process alge- 
braic specifications), but in the intermediate model, by attaching the resets to 
the transitions of the network. 

Various techniques can be used to determine automatically which variables 
can be reset by which transitions. A simple approach consists in resetting all 
the variables of a process as soon as this process terminates. This approach was 
implemented in CAESAR 4.3 (January 1992) and gives significant reductions 1 for 
terminating processes (especially at the points corresponding to the sequential 
composition (“»”) and disabling (“ [>”) operators of Lotos, which are detected 
by analysing the structure of the network model), but not for cyclic (i.e., non- 
terminating) processes. The Xmc model checker uses a similar approach [6], 
with two minor differences: dead variables are determined by analysing the se- 
quential composition of processes at the source level and are removed from the 
representation of the state instead of being reset 2 . 

A more sophisticated approach was studied in 1992-1993 by the first author 
and one of his MSc students [7] in order to introduce variable resets everywhere 
it would be possible, including in cyclic processes. A key idea in [7] was the 
computation of variable resets by means of classical data-flow analysis techniques 
(precisely, dead variable analysis), such as those used in optimising compilers for 
sequential languages. An experimental version of CiESAR implementing this idea 

1 For the “rel/REL” reliable atomic multicast protocol, CfiSAR 4.3 generated a state 
space of 126,223 states and 428,766 transitions in 30 minutes on a DEC Station 5000 
with 24 MB RAM, while C*sar 4.2 would generate a state space of 679,450 states 
and 1,952,843 transitions in 9 hours on the same machine. 

2 See the concerns expressed in [12] about the poor efficiency of such a variable-length 
state representation scheme. 
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was developed in 1993. Although it gave significant state space reductions, it also 
happened to produce incorrect results on certain examples, which prevented it 
from being integrated in the official releases of CiESAR. The reason for these 
errors was unknown at that time, but is now understood and addressed in this 
paper. 

The use of data-flow analysis for resetting dead variables was later mentioned 
in [12] and formalised in [3, 4], the main point of which is the proof that reduction 
based on dead variable analysis preserves strong bisimulation. Compared to [7], 
[3,4] target at the Sdl language rather than the Lotos process algebra, and, 
instead of the network model, consider a set of communicating automata with 
state variables that are consulted and assigned by the automata transitions. The 
main differences between the model of [3,4] and the network model are twofold. 

As regards system architecture, the network model allows concurrent pro- 
cesses to be nested one in another at an arbitrary depth; this is needed for a 
compositional translation of process algebra specifications in which parallel and 
sequential composition operators are intertwined arbitrarily - such as the Lotos 
behaviour ll Bi»(B 2 \ I I A? 3 ) >>J5 4 ” expressing that the execution of process B 1 
is followed by the concurrent execution of two processes B 2 and B 3 , which, upon 
termination of both, will be followed by the execution of process B 4 . On the 
contrary, the model of [3,4] lacks any form of process hierarchy by allowing only 
a “flat” collection of communicating automata, all activated in the initial state. 

As regards interprocess communications, the network model implements the 
Hoare-style rendezvous mechanism used in process algebras by synchronised 
Petri net transitions, which allow data exchanges between processes; additionally, 
concurrent processes may share variables inherited from their parent process(es) 
- as in the Lotos behaviour ll G?X:S\ ( B±\ I \B 2 )”, in which both processes 
B 1 and B 2 can use variable X of sort S, whose value has been set in their 
parent process; these shared variables are read-only, in the sense that children 
processes cannot modify them. On the contrary, the model of [3, 4] relies on Fifo 
message queues and shared variables that can be arbitrarily read/ written by all 
the processes. As regards shared variables, [3,4] propose an approach in which 
variable resets are computed partly at compile-time (when analysing each com- 
municating automaton separately) and partly at run-time (when generating all 
reachable states of the product automaton) . Although it is difficult to figure out 
how this approach can be implemented in practice - since the authors stand far 
from algorithmic concerns and since the most recent versions 3 of their If tool set 
[5] do not reset shared variables actually - we believe that the communicating 
automata model used by [3, 4] is not sufficient in itself to express resets of shared 
variables, so that some extra information (yet to be specified) must be passed 
from compile-time to run-time. In comparison, the approach presented in this 
paper can be performed entirely at compile-time and requires no addition to the 
network model. 

This paper is organised as follows. Section 2 presents the network model and 
its operational semantics. Sections 3 and 4 respectively present the local and 



Namely, If 1.0 (dated November 2003) and If 2.0 (dated March 2003). 
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global data-flow analyses of [7] for determination of variable resets. Section 5 
deals with the particular case of inherited variables, which need careful attention 
to avoid semantic problems caused by a “naive” insertion of resets. Section 6 
reports about experimental results and Sect. 7 gives concluding remarks. 

2 Presentation of the Network Model 

The network model presented here is based on the definitions of [8,10], the 
essential characteristics of which are retained (namely, the Petri net structure 
with state variables); but it also contains some more recent extensions that 
proved to be useful. 

Formally, a network is a tuple (Q, Qo,U, T, Q, X, S, T), the components of 
which will be presented progressively, so as to avoid forward references. We will 
use the following convention consistently: elements of set Q ( resp . U, T, Q, X, 
S, T ) are noted by the corresponding capital letter, e.g. Q, Qo, Q i, Q ' , Q", etc. 

Sorts, Functions, and Variables. In the above definition of a network, S denotes 
a finite set of sorts (i.e. , data types), T denotes a finite set of functions, and 
X denotes a finite set of (state) variables. We note domain(S) the (possibly 
infinite) set of ground values of sort S. Functions take (zero, one, or many) 
typed arguments and return a typed result. Variables also are typed. 

Contexts. To represent the memory containing state variables, we define a con- 
text C as a (partial) function mapping each variable of X either to its ground 
value or to the undefined value, noted “_L”. We need 5 operations to handle con- 
texts. For contexts C\ and C 2 , and variables Wo, . . . , X n , we define the contexts: 
{}: X h- > i (i.e., the empty context) 

{Wo i— > u}: X i— > if X = Wo then v else J_ 

- Ci 0 {W 0 , ... , W„}: W ^ if W G {W 0 , . . . , X n } then _L else C\ (W) 

- Ci 0 C 2 : W h-> if C 2 (W) ^ _L then C 2 (W) else Ci(W) 

- Ci © C 2 : W h-> if C 2 (W) ± T then C 2 ( W) else Ci(W) 

Weonlyuse®on “disjoint” contexts, i.e., when (Cl(W) = _L) v(C 2 (W)=_l_). 

Value Expressions. A value expression is a term built using variables and func- 
tions: V ::= X | F(V i, . . . , V n >o). We note eval(C, V) the (unique) ground value 
obtained by evaluating value expression V in context C (after substituting vari- 
ables with their ground values given by C and applying functions). Because the 
network is generated from a Lotos specification that is correctly typed and 
well-defined (i.e., each variable is initialised before used), evaluating a value ex- 
pression never fails due to type errors or undefined variables. 

Offers. An offer is a term of the form: O ::= ! V j ?W :S \ 0\ . . . O n > o, mean- 
ing that an offer is a (possibly empty) sequence of emissions (noted “!”) and/or 
receptions (noted “?”). We define a relation noted “[C, O] [C , v\ . . . u„]” ex- 
pressing that offer O evaluated in context C yields a (possibly empty) list of 
ground values V\ . . . v n and a new context C' (C' reflects that ?W : S binds X to 
the received value(s)). For given pair [C, O] there might be one or several pairs 
[C , v\. .. v n ] such that [C, O] [C , V\... v n ], since a reception ?W : S generates 
as many pairs as there are ground values in domain(S) . 
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v~eval{C,V) v £ domain(S) Vi € {1, . . . , n} [C, Oi\ A [Ci,Vi] 

[C, !V] A [{},«] [c, ?X:S] A [{*_>,,},«] [C,0 1 ...0 n ]A[©7 =i a, V 



Actions. Actions are terms of the form: 

A ::= none (empty action) 

| when V (condition) 

| for A' among S (iteration) 

| A'o, . . . , A„>o : =Vo, . . . , V n (vectorial assignment) 

reset X 0 , . . . , A'„>o (variable reset) 

| Ai;A 2 (sequential composition) 

| A1&A2 (collateral composition) 

We define a relation noted “[C, A] AC"” expressing that successful execution of 
action A in context C yields a new context C' . For given pair [C, A] there might 
be zero, one, or several C' such that [C,A\ —>C', since a “when V” condition 
may block the execution if V evaluates to false, whereas a “for X among 5” 
iteration triggers as many executions as there are ground values in domain(S) . 

eval (C, V ) = true v £ domain(S) [C, X : =v\ A C' 



[i C , none] AC [C, when V ] —> C 

C' = C<Z) 0'L O {^ ■-> evaljc, Vi)} 



\C. for A among 5] C' 

C' = CQ{ A 0 ,...,A n } 



[C, X 0 ,...,X n :=V 0 ,...,V n }- 
[C,A 1 ]^C [C',A 2 ]AC" 



► C" [C, reset A 0 , . . . , A „]4C' 
[C,A i; A 2 ]AC" [C,d 2 ;A]^C" 



[C,A i; A 2 ]AC" 



[c,A!&a 2 ]Ac" 



Gates. In the above definition of a network, 1/ denotes a finite set of gates 
(i.e. , names for communication points). There are two special gates: “r”, the 
usual notation for the internal steps of a process, and “e”, a powerful artefact 
(see [8, 10]) allowing the compositional construction of networks for a large class 
of Lotos behaviours such as “B 1 [] (f? 2 I I I S3)”. Although £ deserves a special 
semantic treatment, this has no influence on the approach proposed in this paper; 
thus, we do not distinguish e from “ordinary” gates. 



Places and Transitions. In the above definition of a network, Q denotes a finite 
set of places, Qq £ Q is the initial place of the network, and T denotes a finite set 
of transitions. Each transition T is a tuple (Qi, Q 0 , A, G, O, W, R), where Qi C Q 
is a set of input places (we note in(T) = Qi), Q a C Q is a set of output places 
(we note out{T) = Q 0 ), A is an action, G is a gate, O is a (possibly empty) 
offer, W is a when-guard (i.e., a restricted form of action constructed only with 
“none”, “when”, and “&”), and R is a reaction (i.e., a restricted form of 
action constructed only with “none” , “ : =” , “reset” , “ ; ” , and ) . 

Markings. As regards the firing of transitions, the network model obeys the 
standard rules of Petri nets with the particularity that it is one-safe, i.e., each 
place may contain at most one token - this is due to the so-called static con- 
trol contraints [2, 8, 10], which only allow a statically bounded dynamic creation 
of processes (for instance, the following behaviour “J5i»(i?2l I 1 .63) >>54” is 
permitted, whereas recursion through parallel composition is prohibited). 
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Fig. 1. Example of a network 

Therefore, we can define a marking M as a subset of the places of the network 
(i.e. , M C Q). We define the initial marking Mq = {Qo}, which expresses that, 
initially, only the initial place of the network has one token. We define a relation 
noted “[M, T] — ► M'” meaning that transition T can be fired from marking M, 
leading to a new marking M' . Classically, [M, T]—>M' holds iff in(T ) C M (i.e., 
all input places of T have a token) and M' = (M \ in(T)) U out(T ) (i.e., tokens 
move from input to output places). 

Units. Contrary to standard Petri nets, which consists of “flat” sets of places 
and transitions, the places of a network are properly structured using a tree- 
shaped hierarchy of units. The set of units, which is finite, is noted Lt in the 
above definition of a network. To each unit U is associated a non-empty, finite 
set of places, called the proper places of U and noted places (U), such that all 
sets of proper places {places(U) \ U £ U} form a partition of Q. Although units 
play no part in the transition relation “[M, T) M'" between markings, they 
satisfy an important invariant: for each marking M reachable from the initial 
marking Mq and for each unit U, one has card[M fl places{U )) < 1, i.e., there 
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is at most one token among the proper places of U, meaning that each unit 
models a (possibly inactive) sequential behaviour. This invariant serves both for 
correctness proofs and compact memory representation of markings. 

Units can be nested recursively: each unit U may contain zero, one, or several 
units, called the sub-units of U\ this is used to encapsulate sequential or concur- 
rent sub-behaviours. There exists a root unit containing all other units. We note 
U U' C U” the fact that U' is equal to U or transitively contained in U: this rela- 
tion is a complete partial order, the maximum of which is the root unit. We note 
places* (U) = (Jy nu places(U') the set of places transitively contained in U. For 
some marking M reachable from Mo, one may have card (tfn places* (£/)) > 1 in 
case of concurrency between the sub-units of U; yet, for all units U and U' C U , 
one has (M n places (U) = 0 ) V (M fl places (U') = 0 ), meaning that the proper 
places of a unit are mutually exclusive with those of its sub-units. 

Variables may be global , or local to a given unit. We note unit(X) the unit 
to which variable X is attached (global variables are attached to the root unit) . 
A variable X is said to be inherited in all sub-units of unit(X). In a first ap- 
proximation, we will say that variable X is shared between two units U\ and U2 
iff (Ui C unit(X )) A (U2 C unit{X )) A (U\ % U2) A (U2 % U\)\ this definition 
will be sufficient until Sect. 5 , where a refined definition will be given. 

Labelled Transition Systems. Finally, the operational semantics of the network 
model is defined as a Labelled Transition System (LTS), i.e., a tuple (A, <jg, £, — >) 
where A is a set of states, erg € A is the initial state, C is the set of labels and 
-»CAx£xAis the transition relation. 

The LTS is constructed as follows. Each state of A consists of a pair ( M , C), 
with M a marking and C a context. The initial state <jg is the pair (Mq,{}), 
i.e., one token is in the initial place and all variables are undefined initially. Each 
label of £ consists of a list G v\ . . . v n , with G a gate and V\ . . . v n a (possibly 
empty) list of ground values resulting from the evaluation of an offer. A transition 

(cti, L, 02) belongs to the >” relation, a fact which we note “a 1 02”, iff 

[M,T\™M’ [C,A]^C [C',Q\^[C",v 1 ...v n } [C" \R)\-^C"' 

(M, C) A (M', C"') 

The above definition expresses that firing a transition involves several steps, the 
execution of each must succeed: the action is executed first, then the offer is 
evaluated, then the when-guard is checked, and the reaction is executed finally. 
In fact, the actual definition of the transition relation is more complex because 
there are rules to eliminate e-transitions from the LTS; as mentioned before, we 
do not detail these rules here. 

Example. Figure 1 gives an example of a network. According to Petri Net graph- 
ical conventions, places and transitions are represented by circles and rectangles. 
Dashed boxes are used to represent units. For each transition, the corresponding 
action, gate and offer, when-guard, and reaction are displayed (in that order) 
from top to bottom on the right; we omit every action, when-guard, or reaction 
that is equal to none. The variables attached to U\ are Xi and Z\\ those at- 
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tached to U2 are X2 and Z2 ; those attached to U3 are M, N, X, Y, Y\, and In- 
variable X inherited from U3 is shared between U4 and U5. 

3 Local Data-Flow Analysis 

In the network model, transitions constitute the equivalent of the “basic blocks” 
used for data-flow analysis of sequential programs. We first analyse the flow of 
data within each transition taken individually to characterise which variables 
are accessed by this transition. Our definitions are based on [ 7 ] with adaptations 
to take into account the latest extensions of the network model and to handle 
networks that already contain “reset” actions. We define the following sets by 
structural induction over the syntax of value expressions, offers, and actions: 

- use v (V) ( resp . use o ( 0 ), use a (A)) denotes the set of variables consulted in 
value expression V (resp. offer O, action A). 

- def o ( 0 ) (resp. def a (A)) denotes the set of variables assigned a defined value 
by offer O (resp. action A). 

- unda(A) denotes the set of variables assigned an undefined value (i.e., reset) 
by action A. 

- use-before-def a (A ) denotes the set of variables consulted by action A and 
possibly modified by A later (modifications, if present, should only occur 
after the variables have been consulted at least once). 



use v {X) = {X} 

A n 

US e v (F{V u...,V n ))= U use v (Vi) 

i= 1 


use 0 ('.V) = use v (V ) 
use 0 (?X:S) = <6 

A n 

use o ( 0 1 . . . On) = U use 0 (Oi) 

i = 1 


imda(reset Xo, ■ . . , X n ) = {Xo , . . . , Xn} 
und a (Ai;A2) = ( und. a (A \ ) \ def a (A2)) U und a (A2) 
und a (AifcA2) = unda(Ai) U und a {A2) 
otherwise : und a (A) = 0 


def 0 (\V)^<b 

def 0 (?X:S)^{X} 

A n 

def 0 (Oi . . . O n ) = U defAOi) 

i = 1 


def a (X o, . . . , X n :=Vo, ■ ■ ■ ,Vn) = (A 0 , . . . , X n } 

def a (for X among S ) = {A} 

de f a {Ai;A 2 ) = (def a (Ai) \ und a (A 2 )) U def a (A 2 ) 

def a {Ai&A 2 ) = def a (Ai) U de/ a (A 2 ) 

otherwise : def a (A) = 0 


use a ( when V) = use v (V ) 
a n 

use a (X 0 . . . :=Vo ■ ■ •) = U use v (Vi) 
i = 0 

use a (Ai ; A 2 ) = use a (Ai ) U use a (A 2 ) 
?rse a (Ai&A 2 ) = use a (Ai) U use a (A 2 ) 
otherwise : use a (A) = 0 



useJ>efore_d,ef a (A\',A2) = usf:_before-deJ a (A \ ) U ( useJ)efore-def a ( A 2 ) \ def a (Ai)'j 
useJ)efore-def a (A1&.A2) = use- befo re_ d ef a ( A 1 ) U use-before_def a (A2) 
otherwise : use-before-def a (A) = use a (A) 



Finally, for a transition T = (Qi, Q 0 , A 1 G, O, W, R) and a variable X , we 
define three predicates, which will be the only local data-flow results used in 
subsequent analysis steps: 

- use(T,X) holds iff X is consulted during the execution of T. 

def(T,X ) holds iff X is assigned a defined value by the execution of T, i.e., 
if X is defined by A, O or R, and not subsequently reset. 
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- use -before -def (T, X) holds iff if X is consulted during the execution of T 
and possibly modified later (modification, if present, should only occur after 
X has been consulted at least once). 

Formally: 



use{T , X) = X £ use a (A ) U use 0 (0) U use a (W) U use a {R ) 

def (T, X) = X £ (( def a (A ) U def 0 {0)) \ und a (R )) U def a {R) 

, j- , rim xr\ a „ ( use-before-def n (A) U (use o (0) \ def n (A )) U 

us e -before -def (T,X) = X £ \ , f, J a } ’ , , j/Ln 

V ( use-before.def a {W-,R ) \ ( def a {A ) U def 0 {0 ))) 



Example. For the variable N in the network of Fig. 1, we have: use(T,N) for 
T £ {r 4 ,T 5 ,T 8 ,T 9 ,T 10 }, def(T,N) for T £ {T 2 ,T 8 }, and use -before -def (T, N) 
for T £ {r 4 ,T5,T 9 ,Tio}. 



4 Global Data-Flow Analysis 

Based on local (intra-transition) data-flow predicates, we now perform global 
(inter-transition) data-flow analysis, the goal being to compute, for each transi- 
tion T = (Qi, Q 0 , A, G, O, W, R) and for each variable X, a predicate reset(T, X) 
expressing that it is possible to reset variable X at the end of transition T (i.e., 
to append “reset X ” at the end of A if X is neither defined in O nor used in 
O, W, and R, or else to append “reset X” at the end of R). To be exact, if A" 
is an inherited shared variable, it is not always possible to insert “reset X” at 
the end of every transition T such that resetfT , X); this issue will be dealt with 
in Sect. 5; for now, we focus on computing reset(T, X). 

For sequential programs, the classical approach to global data-flow analysis 
(e.g. [1]) consists in constructing a control-flow graph on which boolean pred- 
icates will then be evaluated using fixed point computations. The vertices of 
the control-flow graph are usually the basic blocks connected by arcs expressing 
that two basic blocks can be executed in sequence. Since the control-flow graph 
is a data-independent abstraction, it represents a superset of the possible exe- 
cution paths, i.e., some paths of the control-flow graph might not exist in actual 
executions of the sequential program. 

A significant difference between sequential programs and our setting is that 
networks feature concurrency. One could devise a “true concurrency” extension 
of data-flow analysis by evaluating the boolean predicates, not on control-flow 
graphs, but directly on Petri nets. Instead, following [7], we adopt an “interleav- 
ing semantics” approach that maps concurrency onto a standard control-flow 
graph, on which the boolean predicates can be evaluated as usual. 

To abstract away concurrency from the network model, various possibilities 
exist, leading to different control- flow graphs. One possibility would be to base 
the analysis on the graph of reachable markings of the underlying Petri net; 
this would be accurate but costly to compute, as state explosion might occur. 
Hence, we choose a stronger abstraction by defining the control-flow graph as the 
directed graph CFG = (T, — >), the vertices of which correspond to the transitions 
of the network and such that there is an arc Xi — > X 2 iff out(T\) H m(T 2 ) 0. 



State Space Reduction for Process Algebra Specifications 173 





Example. The CFG corresponding to the network of Fig. 1 is shown in Fig. 2. 

Instead of constructing a unique CFG valid for all variables, [7] suggests 
to build, for each variable X , a dedicated control-flow graph CFGa, which is a 
subset of CFG containing only the execution paths relevant to X (nowadays, this 
would be called “slicing”). According to [7, § 4.3.3], such a restricted control- 
flow graph increases the algorithmic efficiency; by our accounts, it also gives 
more precise data-flow results. 

To define CFGa formally, we need two auxiliary definitions. Let trans(U) = 
{T\( in{T ) U out(T )) D places* (U) ^ 0} be the set of transitions with an input 
or an output place in unit U. Let scope(X) be (an upper-approximation of) the 
set of places through which the data-flow for variable X passes. Following the 
simple, “syntactic” approximation of scope(X) given in [7], we define scope(X) = 
places* (unit(X)') as the set of all places in the unit to which X is attached. 

We now define CFGa as the directed graph (7a, — >a) with the set of vertices 
7a = trans (unit(X)) and such that there is an arc T\— >xT 2 iff OMt(7~i)nm(7"2)n 
scope(X) 0. For T £ 7a, we note succx(T) = {T' £ Tx | T— s-aT 1 '} and 
predx(T) = {T' £T X \T'^xT}. 

Example. Figure 3 shows CFGa for the network of Fig. 1 and variable N; notice 
that I 4 — > 7g, but not T 4 — >A7g. 

Following the classical definition of “live” variables (e.g. [1, pages 631-632]), 
we define, for T £ Tx, the following predicate: 

live(T,X) = Vt esuccx(T) use-before-def (T' , X) V {live(T' , X) A ~^def{T ' , X)) 
that holds iff after T it is possible, by following the arcs of CFGa, to reach a 
transition T' that uses X before any modification of X. For a given X, the set 
{T £ 7a j live(T,X)} is computed as a backward least fixed point. 

We could now, as in [3,4], define reset(T,X) = -> live(T,X). Unfortunately, 
this simple approach inserts superfluous resets, e.g. before a variable is initialised 
or at places where a variable has already been reset. For this reason, one needs 
an additional predicate: 

available (T, X) = def{T,X)\/ [\l T &predx ( T ) (UveiT 1 , X) A available (T 1 , X))^ 
that holds iff T can be reached from some transition that assigns X a defined 
value, by following the arcs of CFGa and ensuring that X remains alive all along 
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the path. For a given X, the set {T £ Tx \ available(T, X)} is computed as a 
forward least fixed point. [7] uses a similar definition without the live(T',X) 
condition and, thus, only avoids resetting uninitialised variables. 

Finally, we define reset(T : X) = available(T , X)A —<live{T, X), expressing that 
a variable can be reset where it is both available and dead. 

Example. For the network of Fig. 1 and variable N , we have {T \ live(T , N)} = 
{T2,T 8 } and {T \ available (T, X)} = {T 2 , T4, T 5 , Tg, T g , T 10 }. Thus, we can insert 
“reset X” at the end of T4, T5, Tg, and Tio- Using the definition of [3,4], one 
would insert superfluous “reset X” at the end of To, Tg, and T7. Using the 
definition of [7], one would insert superfluous “reset X” at the end of Tg and T7. 
Using CFG instead of CFGat would give {T | live(T, X)} = {To . . . T5, Tg . . . T12} 
and {T | available(T , X)} = {Ti . . . T5, Tg . . . T12}, so that no “reset X” at all 
would be inserted. 

5 Treatment of Inherited Shared Variables 

Issues when Resetting Shared Variables. Experimenting with the approach of 
[7], we noticed that systematic insertion of a “reset A"” at the end of every 
transition T such that resetfT, X) could produce either incorrect results (i.e., 
an LTS which is not strongly bisimilar to the original specification) or run-time 
errors while generating the LTS (i.e., accessing a variable that has been reset). 
Example. In the network of Fig. 1, there exists a fireable sequence of transitions 
To,Ti,T 2 ,T4,T 6 ,T7. Although reset(T 6 , X) is true, one should not reset A' at 
the end of Tq, because X is used just after in T7. Clearly, the problem is that T 6 
and T-j are two “concurrent” transitions sharing the same variable X. This was 
no problem as long as X was only read by both transitions, but as soon as one 
transition (here, Tq) tries to reset X, it affects the other transition (here, T7). 

So, insertion of resets turns a read-only shared variable into a read/ write 
shared variable, possibly creating read/write conflicts as in a standard reader- 
writer problem. The sole difference is that resets do not provoke write/ write 
conflicts (concurrent resets assign a variable the same undefined value). 

To avoid the problem, a simple solution consists in never resetting inher- 
ited shared variables (as in the If tool set [5]). Unfortunately, opportunities for 
valuable state space reduction are missed by doing so. 

Example. As shown in Fig. 4 (a) and (b), the LTS generated for the Lotos 
behaviour “G?X:bit; (Gi!X;stop| I |G2!X;stop)” has 9 states if the inher- 
ited shared variable X is not reset, and only 8 states if X is reset after firing 
transitions Gi ! X and G 2 ! X (state space reduction would be more substantial 
if both occurrences of “stop” were replaced by two complex behaviours B 1 and 
B2 in which the value of X is not used). Figure 4 (c) shows the incorrect LTS 
obtained by resetting X to 0 after each transition Gi !X and G 2 ! X. 

Duplication of Variables. The deep reason behind the issues when resetting 
inherited shared variables is that the control-flow graphs CFG and CFGjc de- 
fined in Sect. 4 are nothing but approximations. Their definitions follow the 
place-transition paths in the network, which has the effect of handling similarly 
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Fig. 4. LTS (a) without reset, (b) with correct resets, and (c) with incorrect resets 



nondeterministic choice (i.e., a place with several outgoing transitions) and asyn- 
chronous concurrency (i.e., a transition with several output places). Indeed, both 
Lotos behaviours “G; (Bi I I H? 2 )” and “G; (_Bi[]I? 2 )” have the same CFG. 
These approximations produce compact control-flow graphs, but are only correct 
in absence of data dependencies (caused by inherited shared variables) between 
“concurrent” transitions. 

To address the problem, we introduce the notion of variable duplication. For 
an inherited variable X shared between two concurrent behaviours B\ and B 2 , 
duplication consists in replacing, in one behaviour (say, B2), all occurrences of 
X with a local copy X' initialised to X at the beginning of £? 2 . This new vari- 
able X' can be safely reset in £? 2 without creating read/write conflicts with B\. 
A proper application of duplication can remove all data dependencies between 
“concurrent” transitions, hence ensuring correctness of our global data-flow anal- 
ysis approximations. It also enables the desired state space reductions. 

Example. In the previous example, duplicating X in i? 2 yields the Lotos 
behaviour “G? A' : bit ; let X’ :bit=A in (Gi ! X ;stop I I I G 2 ! A'; stop)”, in 
which it is possible to reset A' after the G \ ! X transition and X' after the 
G 2 !A' transition; this precisely gives the optimal LTS shown on Fig. 4 (b). 
Note that it is not necessary to duplicate A in B\. 

Instead of duplicating variables at the Lotos source level, as in the above ex- 
ample, we prefer duplicating them in the network model, the complexity of which 
has already been reduced by detecting constants, removing unused variables, 
identifying variables local to a transition, etc. Taking into account that concur- 
rent processes are represented by units, we define the duplication of a variable 
X in a unit U, with U C unit.(X) and U yf unit(X), as the operation of creating 
a new variable X' of the same sort as X attached to U (whereas X is attached 
to unit(X)), replacing all occurrences of A' in the transitions of trans(U) by X' 
and adding an assignment “X 1 : =X” at the end of all transitions T £ entry (U) 
such that live(T, X), where entry{U) = {T £ trans(U) \ in(T) n places* (U) = 0} 
is the set of transitions “entering” U. 
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In general, several duplications may be needed to remove all read/ write con- 
flicts on a shared variable X. On the one hand, if X is shared between n concur- 
rent behaviours, (n — 1 ) duplications of X may be necessary. On the other hand, 
each new variable X' duplicating X might itself be shared between concurrent 
sub-units, so that duplications of X' may also be required. 

Concurrency Relation between Units. We now formalise the notion of “concur- 
rent units”. Ideally, two units Ui and Uj are concurrent if it exists a reach- 
able state (M, C) in the corresponding LTS such that the two sets of places 
(M 0 places* (Ui)) and ( Mf)places*(Uj )) are both non empty and disjoint (mean- 
ing that Ui and Uj are “separate” and simultaneously “active” in marking M). 
Example. In the Lotos behaviour “(.Bi I I I .E?2 ) >> C^?3 I I \Bf)” , units U\ and U2 
corresponding to B 1 and B2 are concurrent, units U3 and U4 corresponding B3 
and B4 also, but neither U\ nor U2 is concurrent with either U3 or f/4. 

Practically, to avoid enumerating all states of the LTS, we need a relation 
noted “Ui || Uj” that is an upper-approximation of the ideal definition above, i.e. , 
Ui and Uj concurrent implies Ui || Uj. We base our definition on an abstraction 
function a : Q — ♦ { 1 , . . . , iV } (N being the number of units in the network) that 
maps all the proper places of each unit to the same number: \/Q £ places(Ui): 
a(Q) = i. We extend a to sets of places by defining a : p(Q ) — > p({ 1 , . . . , N}) 
such that a({Qi , . . . , Q n }) = {a(Qi), . . . , a(Q n )}. We then use a and a to 
“quotient” the network, yielding a Petri net with N places numbered from 1 
to N, with initial place a(Q 0) (Q 0 being the initial place of the network), and 
which possesses, for each transition T in the network, a corresponding transition 
t such that in(t) = a(in(T)) and out(t) = a(out(T)) - “self-looping” transitions 
such that in(t) = out(t), as well as transitions identical to another one, can 
be removed. As the number of units is usually small compared to the number 
of places, one can easily generate the set A4 of all reachable markings for the 
quotient Petri net. Finally, we define Ui || Uj iff there exists M £ A4 such that 
both sets (M D a(places* (Uf))) and (M D a(places* (U )))) are not empty and 
disjoint. Notice that Ui || Uj implies Ui Uj, Ui % Uj, and Uj % Ui. 

Conflicts between Units. For two units Ui and Uj such that Ui || Uj, let 
ancestor(Ui,Uj) denote the largest unit U such that Ui UU and Uj % U and let 
link(Ui, Uj) denote the set of transitions connecting the ancestors of U, and those 
of Uj ; formally: link(Ui, Uj) = trans (ancestor (Ui, Uj)) Ctrans (ancestor (Uj, Ui)). 

To characterise whether two units Ui and Uj are in conflict for variable X 
according to given values of predicates use and reset, we define the predicate: 
conflict(Ui,Uj,X, use, reset) = Ui C unit(X) A UjQunit(X) A Ui\\Uj A 
( 3 Ti £ trans(Ui) \ link(Ui, Uj)) ( 3 Tj £ trans(Uj) \ link(Ui, Uj)) 
(reset(Ti, X) A use(Tj,X )) V (reset(Tj,X) A use(Ti, X)) 
Intuitively, units Ui and Uj are in conflict for X if there exist two “indepen- 
dent” transitions Ti and Tj likely to create a read/ write conflict on X. To avoid 
irrelevant conflicts (and thus, unnecessary duplications), one can dismiss the 
transitions of link(Ui,Uj), i.e., the transitions linking the ancestor of Ui with 
that of Uj, since the potential impact of these transitions on the data-flow for 
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1. compute the relation Ui || Uj and link(Ui, Uj ) (cf. Sect. 5) 

2. VARS : =X 

3. while VARS ^ 0 do 

4. begin 

5. X :=one-of( VARS) 

6. VARS : = VARS \ {X } 

7. repeat 

8. for all T £ trams (unit (X)) do 

9. compute use(T, X), def(T,X), and useJ>efore-def{T,X ) (cf Sect. 3) 

10. forall T £ trans (unit(X)) do 

11. compute reset(T, X) (cf Sect. 4) 

12. compute conflict(Ui,Uj , X, use, reset) and UCGx (cf Sect. 5) 

13. compute U :=best_of(UCGx) (cf. Sect. 5) 

14. if U =£ _L then 

15. begin 

16. duplicate X in U by creating a new variable X' 

17. VARS : = VARS U{A'} 

18. end 

19. until U = . L 

20. — at this point, there is no more conflict on X 

21. forall T £ trans (unit (X)) such_that reset(T, X) do 

22. insert “reset X” at the end of T (cf. Sect. 4) 

23. end 



Fig. 5. Complete algorithm 

X has already been considered when constructing CFGx and computing reset 
- based on the observation that link(Ui , Uj) C trans (unit(X)) . 

We then define, for given values of predicates use and reset, the unit conflict 
graph for variable X, noted UCGx , as the undirected graph whose vertices 
are the units of unit(X) and such that there is an edge between Ui and Uj iff 
conflict(Ui, Uj, X, use, reset). 

Complete Algorithm. The algorithm shown in Fig. 5 operates as follows. VARS 
denotes the set of all variables in the network, which might be extended progres- 
sively with new, duplicated variables. All the variables X in VARS are processed 
individually, one at a time, in an unspecified order. For a given A", the algorithm 
performs local and global data-flow analysis, then builds UCGx- If UCGx has 
no edge, X needs not be duplicated and “reset A” can be inserted at the end of 
every transition T £ trans (unit (A')) such that reset(T, X). Otherwise, A must 
be duplicated in one or several units to solve read/write conflicts. This adds to 
VARS one or several new variables A', which will be later analysed as if they 
were genuine variables of the network (i.e., to insert resets for X' and/or to solve 
read/ write conflicts that may still exist for A'). Everytime a new variable X' 
is created to duplicate A", data-flow analysis for X and UCGx are recomputed, 
as duplication modifies the network by removing occurrences (definitions, uses, 
and resets) of A and by adding new assignments of the form X' : =A. 
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Since each creation of a new variable X' increases the size of the state rep- 
resentation (thus raising the memory cost of model checking), it is desirable to 
minimise the number of duplications by choosing carefully in which unit(s) X 
will be duplicated. Based on the observation that duplicating X in some unit U 
removes from UCG x all conflict edges connected to U, the problem is similar to 
the classical NP-complete “vertex cover problem” , except that each edge removal 
provokes the recalculation of UCGx ■ To select the unit (noted besGof(UCGx)) 
in which X should be duplicated first, we adopt a combination of top-down and 
greedy strategies by choosing, among the units of UCGx having at least one 
edge, outermost ones; if there are several such units, we then choose one having 
a maximal number of edges; if UCG x has no edges, best_of(UCGx) returns J_. 

For a given variable X, the “repeat” loop (line 7) terminates because of 
fixed point convergence of global data-flow analysis and because the cardinal of 
Ux = {U G unit(X) | 3 T £ trans(U) \ entry(U) such that use(T, X)} strictly 
decreases at each duplication (line 16). Indeed, Ux is the set of units U in 
which variable X is used within a transition T that does not “enter” U (i.e. , 
in(T ) n places* (U) ^ 0). After duplicating X in U, there are no remaining 
occurrences of X in the transitions of trans (U)\entry(U) and, thus, U is no longer 
in Ux- While duplication might add assignments X' : =X (and consequently, new 
uses of A") to the transitions T of entry (U) (in fact, only those T such that 
live(T,X )) and, therefore, might add to Ux some new unit(s) U' such that 
U C U' G unit(X ), this is not the case actually, as all such units U' already 
belong to Ux (since U £ Ux and U G U' G unit(X) implies U' £ Ux)- 

The outermost “while” loop (line 3), which removes one variable X from 
VARS but possibly inserts new variables X' in this set, also terminates. Let S(U) 
be the nesting depth of unit U in the unit hierarchy, i.e., the number of parent 
units containing U (the root unit having depth 0). Let L = max{5(Z7) j U £ U} 
be the maximal nesting depth, and let A{ VARS ) be the vector (no, . . . , til) such 
that Vi, rii = card{ X £ VARS \ 8 (unit(X)) = i}. At each iteration of the outer- 
most loop, A(VARS) strictly decreases according to the lexicographic ordering 
on integer vectors of length L , as all variables X' created to duplicate X are 
attached to units strictly included in unit(X), i.e., 8 (unit ( X')) < 8(unit(X)). 



6 Experimental Results 

We implemented our approach in a prototype version of CiESAR and compared 
this prototype with the “standard” version of CiESAR, which, as mentioned in 
Sect. 1, already resets variables but in a more limited way (upon process termi- 
nation only). We performed all our measurements on a Sun Sparc Station 100 
with 1.6 GB RAM. 

We considered 279 Lotos specifications (many of which are derived from 
“real world” applications) for which the entire state space could be generated 
with the “standard” version of CAESAR. For 112 examples out of 279 (40%), 
our approach reduced the state space (still preserving strong bisimulation) by 
a mean factor of 9.7 (with a maximum of 220) as regards the number of states 
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and a mean factor of 13 (with a maximum of 360) as regards the number of 
transitions. For none of the other 167 examples did our prototype increase the 
state space. 

Then, we considered 3 new “realistic” Lotos specifications, for which our 
prototype could generate the corresponding state space entirely, whereas the 
“standard” version of CiESAR would fail due to lack of memory. For one of these 
examples, the “standard” version stopped after producing an incomplete state 
space with more than 9 million states, while our prototype generated an LTS 
with 820 states and 1,500 transitions (i.e., a reduction factor greater than 10 4 ). 

We then extended our set of 279 + 3 examples with 17 new, large examples for 
which our prototype is still unable to generate the entire state space. On these 
299 examples, variable duplication occurred in only 28 cases (9.4%) for which it 
increased the memory size needed to represent a state by 60% on average (most 
of the increase being due to 2 particular examples; for the 26 remaining ones, 
the increase is only of 10% on average). However, on all examples for which the 
“standard” version of CiESAR could generate the LTS entirely, we measured that, 
on average, the increased memory cost of state representation was outweighed 
by the global reduction in the number of states. 

As regards execution time, we observed that our approach divides by a factor 
of 4 the total execution time needed to generate all LTSs corresponding to the 
279 examples mentioned above. The cost in time of our algorithm is small (about 
4%) and more than outweighed by the resulting state space reductions. 

7 Conclusion 

This paper has shown how state space reduction based on a general (i.e., not 
merely “syntactic” ) analysis of dead variables can be applied to process algebra 
specifications. Our approach requires two steps. 

First, the process algebra specifications are compiled into an intermediate 
network model based on Petri nets extended with state variables, which can be 
consulted and modified by actions attached to the transitions. 

Then, data-flow analysis is performed on this network to determine auto- 
matically where variable resets can be inserted. This analysis generalizes the 
“syntactic” technique (resetting variables of a process upon its termination) im- 
plemented in CjESAR since 1992. It handles shared read-only variables inherited 
from parent processes, an issue which so far prevented the approach of [7] from 
being included into the official releases of CiESAR. 

Compared to related work, our network model features a hierarchy of nested 
processes, where other approaches are usually restricted to a flat collection of 
communicating automata. Also, our data-flow analysis uses two passes (back- 
ward, then forward fixed points computations) in order to introduce no more 
variable resets than necessary. 

Experiments conducted on several hundreds of realistic Lotos specifications 
indicate that state space reduction is frequent (20-40% of examples) and can 
reach several orders of magnitude (e.g. 10 4 ). Additionally, state space reduction 
makes CiESAR four times faster when processing the complete set of examples. 
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As regards future work, we can mention some open issues (not addressed in 
this paper, since they are beyond the scope of the CiESAR compiler for Lotos), 
especially data-flow analysis in presence of dynamic creation/destruction of pro- 
cesses (arising from recursion through parallel composition) and data-flow anal- 
ysis for shared read/ write variables (in which case duplication is no longer pos- 
sible) . 
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Abstract. We consider a certain, in a way hybrid extension of a system 
called topologic, which has been designed for reasoning about the spatial 
content of the idea of knowledge. What we add to the language of topo- 
logic are names of both points and neighbourhoods of points. Due to the 
special semantics of topologic these names do not quite behave like nom- 
inals in hybrid logic. Nevertheless, corresponding satisfaction operators 
can be simulated with the aid of the global modality, which becomes, 
therefore, another means of expression of our system. In this paper we 
put forward an axiomatization of the set of formulas valid in all such 
hybrid scenarios, and we prove the decidability of this logic. Moreover, 
we argue that the present approach to hybridizing modal concepts for 
knowledge and topology is not only much more powerful but also much 
more natural than a previous one. 

Keywords: logical frameworks for reasoning, reasoning about knowledge 
and topology, hybridization, completeness, decidability 



1 Introduction 

Logics of knowledge and time are today widely accepted formalisms for analysing 
distributed scenarios 1 . While a temporal component is obviously inherent to 
such systems, it is less recognized that they have a spatial element as well. 
In fact, knowledge can be viewed as closeness and knowledge acquisition as 
approximating points in suitable spaces of sets. In this way topology enters the 
context of evolving knowledge. This was discovered and made precise in the 
paper [3] first, and drawn up in detail in [4]. The basic issue of these papers 
is a rather general bi-modal system called topologic, comprising two one-place 
operators K representing knowledge and □ representing effort (in which time is 
encoded implicitly) . The formulas of the underlying language are interpreted in 
set spaces ( X , O , V) consisting of a non-empty set X of points or states, a set O 
of distinguished subsets of X, which can be taken as knowledge states (changing 
in the course of time) of an agent, and a valuation V determining the states 
where the atomic propositions are true. The operator K quantifies then across 

1 The textbooks [1] and [2] provide comprehensive introductions to this field. 
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any knowledge state, whereas □ quantifies ‘downward’ across O. That is, more 
knowledge, i.e., closer proximity, can be achieved by descending with respect to 
the set inclusion relation inside O , and just this is modelled by □. 

Focussing on the topological part of knowledge leads us to a new area of 
application: why not use topologic as a basic geometric specification tool? Pur- 
suing this idea causes, however, new expressiveness requirements very soon. The 
way we follow here in order to meet these requirements is marked in the title 
of the paper. Two concepts typical of hybrid logic, viz naming and evaluating 
formulas at distinguished states, are added to the source language 2 . When doing 
this we have to be careful, because of the semantics of topologic. As a result, we 
get to a ‘soft’ hybridization of the original system. Nevertheless, our skills with 
regard to expressiveness can be substantially expanded while the nice properties 
of topologic are preserved. 

An ‘orthodox’ hybrid logic of knowledge and time has been developed already, 
cf [8]. The system presented in this paper is, however, much more powerful and 
flexible than that. In particular, the earlier logic can be embedded; see Section 
5 below. 

The paper is organized as follows. The new language for spaces of knowl- 
edge states is introduced in the next section, where a couple of examples too 
are contained in. These examples show on the one hand how the language can 
be applied to modelling evolving knowledge and on the other hand which topo- 
logical properties can be expressed. Section 3 contains an axiom system for the 
resulting hybridized logic of set spaces. Moreover, we touch on the question of 
completeness there. In Section 4 we state the decidability of our logic and out- 
line the proof of this main result of the present paper. A comparison with other 
approaches to ‘hybrid topologic’ is given in the final section. 

It should be mentioned that the system proposed in this paper is related 
to those we presented at previous AMAST conferences; cf [9] and [10]. While 
certain variants of the basic logic of set spaces were studied there, a substantial 
development is yielded in our view by the hybridization carried out here. 



2 The Language 

First in this section we define precisely the syntax and semantics of the logi- 
cal language described colloquially above. Second, we give a couple of examples 
showing how this language can be used for modelling basic frameworks of knowl- 
edge acquisition. Finally, we turn to topology and give sample specifications of 
some fundamental topological notions. In this way the new language proves to 
be an appropriate core language supporting topological reasoning. 

We extend the bi-modal language of topologic by adding both two sets of 
names and a third unary modal operator. The denotation of each of the new 

2 The paper [5] is a very readable introduction to hybrid logic; see also [6], Sec. 7.3. 
The origin of hybrid logic from Prior’s work on temporal representation and the 
part hybrid logic plays for today’s temporal logic are commented on, eg, in [7]. 
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names is either a unique state or a distinguished set of states, whereas the 
further modality represents the global one (cf [6], Sec. 7.1). 

Let PROP = { p , q , . . .} be a denumerable set of symbols called proposition 
variables. Moreover, let N stat = {i,j, . . .} and N se t s = {A, B , . . .} be two further 
sets of symbols called names of states and names of sets, respectively. We assume 
that the sets PROP, N s t at and N sets are mutually disjoint. Then, we define the 
set WFF of well-formed formulas over PROP U N stot U N sete by the rule 

a ::= p \ i \ A \ ->a \ a A (3 \ Ka | Da | A a. 

The missing boolean connectives T, J_, V, — >, <-> are treated as abbreviations, as 
needed. The duals of the modal operators K , □ and A are denoted L, O and E, 
respectively. 

Now we give meaning to formulas. To begin with we have to define the 
domains where formulas are to be interpreted in. In the following we let 'P(X') 
designate the powerset of a given set X. 

Definition 1 (Set spaces with names). 

1. Let X ^ 0 be a set and O C V{X) a set of subsets of X such that X G O. 
Then the pair S := (X, O) is called a set frame. 

2. Let S = (X, O) be a set frame. The set of neighbourhood situations of S is 
Ms := {x, U | x € U and U € O}. 

3. Let S be as above. An 5-valuation is a mapping 

V : PROP U N sta t U N sets — > T{X) 

such that V{i) is either 0 or a singleton subset of X for every i € N stat , and 
V (A) G O for every A G N sets . 

f. A triple M. := (X,0,V), where S = [X, O) is a set frame and V an S 
valuation, is called a set space with names (or, in short, an SSN/ We say 
that M is based on S. 



For a given SSN M we define now the relation of satisfaction, \=m , between 
neighbourhood situations of the underlying frame and formulas in WFF. (The 
obvious clauses for negation and conjunction are omitted.) 



Definition 2 (Satisfaction and validity). 

1 . Let M. = (X, O, V) be an SSN based on S = ( X , O), and x,U a neighbour- 
hood situation of S. Then 



X , U | = J\4 p 

x , U i 

x , U A 

x, U \=m Ka 
x , U \=m Da 
x , U \=m Aa 



x G V(p) 
x € V(i) 



V(A) = U 

y , U |=At a f or all y € U 
V U r G O : {x G W C U implies x, U 1 \=m a ) 
Vi U’ \=m a for all y, U' G Ms, 



where p G PROP, i G N stat , A G N sets , and a G WFF. In case x , U \=m a 
is true we say that a holds in A i at the neighbourhood situation x , U. 
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2. Let M. be an SSN. A formula a is called valid in M. iff it holds in M. at 
every neighbourhood situation of the set frame M. is based on. (Manner of 
writing: M. \= a.) 

Note that the meaning of both proposition variables and names of states is 
regardless of neighbourhoods, thus ‘stable’ with respect to □. 

Because of the second clause in Definition 2.1 a name i £ N sta t reminds one of 
a nominal as known from hybrid logic; cf [5]. However, due to the two-component 
semantics just defined we can not specify accordingly an accompanying satisfac- 
tion operator @j. Solely for names of neighbourhood situations such an operator 
can be mimicked. In fact, formulas of the form i A 4, where i £ N sta t and 
A £ N se ts, can be taken as appropriate names for elements of A/js, and a satis- 
faction operator associated with such a name reads then E(i AiA . . .). I.e., pairs 
(i,A) can act like proper nominals in set spaces with names. 

The following two examples show that the language just defined is closely 
related to knowledge acquisition, actually. 

Example 1. Suppose that an agent (who is an expert in heraldry) can get to 
know which countries of the Continent do not belong to EURO-land in the 
following way: every member of this alliance is represented by an accompanying 
EURO, there is one toss of these 12 coins, and the agent may turn round one 
coin after the other. Let 

A - B - D - 0 - F - 0 - GR - I - IRL - L - NL - 0 

be the outcome of the toss, where ‘0’ indicates the (matching) reverse. Then, 
assuming that the agent knows in advance that no country from Eastern Europe 
is involved, the following sequence of successive knowledge states (i.e., sets of 
states the agent considers possible) results: 

{ Y | card(F) = 5 and Y C {CH, DK, E, FIN, GB, N, P, S}} 

D {Y | card(K) = 5 and Y C {CH, DK, FIN, GB, N, P, S}} 

D {Y | card(F) = 5 and Y C {CH, DK, GB, N, P, S}} 

D {{CH, DK, GB, N, S}} 

More generally, the agent will always get to know the countries not belonging to 
EURO-land by such a scenario . Therefore, the formula OA'non— members holds 
at every initial situation of an SSN constructed from the above set of countries 
in an obvious way, where non— members serves as a name for the knowledge state 
{{CH, DK, GB,N, S}} desired by the agent. 

Example 2. Objects that are potentially infinite can often be represented by 
elements of {0, 1}“ in a natural way. This is true, in particular, for the real 
numbers (for which in fact many natural representations exist). An element 
p £ K. is called computable, iff there is a program computing a binary stream that 
encodes a fast-converging Cauchy sequence having limit p\ see [11]. Now assume 
that an agent wants to acquire some knowledge about an actually computed 
p £ R. A suitable model is based on the Cantor space of all binary streams in 
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such a way that every knowledge state of the agent coincides with a basic open set 
consisting of all possible prolongations of the output the program has delivered 
up to any time. Then, if it is true that p is different from, eg, 7 r, the agent will 
know this eventually and forever afterwards. Thus the formula EK CH7r is valid 
in every SSN based on the Cantor space (where 7r names any stream representing 
this real number). 

The connection between knowledge and spaces of shrinking sets, i.e., topo- 
logical scenarios, is revealed by these examples, in particular. 

Concluding this section we take a step further and give reasons for our the- 
sis that the above language is sufficiently expressive to serve as a topological 
specification language. The examples contained in the following definition and 
proposition, respectively, concern the basic topological ideas of separation and 
connectedness. The use of the global modality is exemplified by expressing the 
fact that set frames are generated in a sense (by any neighbourhood situation 
x,X). 

Definition 3 (Special classes of set frames). Let S = ( X , O) be a set frame. 
Then S is called 

1. separated iff for all x,y £ X such that x ^ y there exists C/i,[/ 2 £ O 
satisfying x £ f7i \ [/ 2 and y £ f/ 2 \ t/i, 

2. connected iff for all U,U\,U 2 € O such that U\ ^ 0 ^ U 2 we have that 
U = U\ U U 2 implies U\ fl U 2 0. 

Proposition 1. Let S = (X,0) be a set frame. Then 

1. S is separated iff M. |= *A L(j A ->i) — ■> OK~<j A I\ ( j — > OKX) for all SSNs 
XI based on S and i,j £ N stat . 

2. S is connected iff XI \= KO(A V B) — > L[OA A O B) for all SSNs XI based 
on S and A,B £ N sets . 

3. XI |= E (Ea — > LOa) for all SSNs XI based on S and a £ WFF. 

Proof. We prove only item 2 3 . First, let S be connected. Let XI be any set space 
with names based on 5, and take any neighbourhood situation x,U of S such 
that x, U \=m KO(A V B) 1 where A, B £ N sets . Then for all y £ U there exists 
U v £ O such that y, U y \ = A V B. That is, U y = V (A) or U y = V ( B ) due to the 
definition of the semantics. It follows from this that U = V(A) U V(B). Since 
U ^ 0 and S is assumed to be connected there exists a point z £ V (A) fl V ( B ) . 
Thus z, U \=m ^^4 A OB, and consequently x, U \=m L(OA A OB), as desired. 

Now suppose that S is not connected. Then there U,U\,U 2 € O such that 
U\ 0 U 2 and U = U\ U U 2 , but Ui fl U 2 = 0- Take any 5-valuation V such 
that V(A) = U\ and V(B) = C/ 2 . Let XV be the SSN which is based on S and 
has S valuation V. Then, clearly, x, U \ =m KO(A V B). But since there is no 
point in the intersection U\ fl f7 2 , we have y, U \=m O-iA or y, U \=m O^B for 

The proof of item 1 can be done in a similar way; item 3 is due to the fact that 
X £ O. 



3 
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all y £ U. Therefore, x,U \=m K(D->A V CH.B) can be concluded. It follows 
that the formula schema given above is not valid in every model. This proves 
the other direction. 

It should be remarked that the separation condition from Definition 3.1 
equals the (T l)-Axiom for topological spaces. Moreover, the notion of connect- 
edness from Definition 3.2 means that all non-empty sets U £ O are connected 
in the topological sense; cf [12], Clr. I, §11, Sec. 1, Definition 2. - The global 
modality is notably important for the proof of Theorem 4 below. 



3 Completeness 



We propose below a sound system of axioms for the logic of set spaces with 
names. Then, a couple of Gabbay-style proof rules 4 is added. This enables us 
to prove completeness of the system. It turns out that we obtain even extended 
completeness (in a sense explained below). Note that almost everything that is 
relevant to the A -free fragment of our language can be found in the paper [13]. 

The axiom schemata are arranged in three groups. First, the usual axioms 
for arbitrary set spaces are listed; cf [4]. 



1. All instances of tautologies. 

2. K(a -> /?) -► (. Ka -> K(3) 

3. Ka — > a 

4. Ka -> KKa 

5. La — s KLa 



6. (p —> dp) A (Op — s p) 

7. □ (a — > /3) — > (Da -s D/3) 

8. Da — » a 

9. Da 

10. KDa -s UKa , 



where p £ PROP and a, (3 £ WFF. - The second group of axioms concerns 
names; cf [13]. (Note the difference between Axiom 14 here and there.) 

11. (* — s □*) A (O i — s i) 14. A (A A La — s L/3) V A (A A L/3 — + La) 

12. * A a — s K(i -► a) 15. I<(OB -s O A) A LOB — s □ (A — s LOB) 

13. A — s KA 16. KOA -> A, 

where i £ N sta t, A, B £ N sets and a, (3 £ WFF. - In the final group, each axiom 
deals with the global modality. In particular, the interplay between A and KD 
is described therein. 

17. A(a — s (3) — s (Aa — > A/3) 19. Aa — > AAa 21. Aa — s KDa 

18. Aa — s a 20. a — > AEa 22. E (Ea — > LOa ) , 

where a, (3 £ WFF. - Note that the last axiom, which is a ‘weak’ converse of the 
penultimate one, equals the formula schema from Proposition 1.3. 

Now we define the desired logical system, which we designate SN G (indicat- 
ing a logic for spaces with names and the global modality). 

4 This naming is meant to refer to Gabbay’s irreflexivity rule (cf, eg, [6], Sec. 4.7 and 
Notes to Ch. 4). 
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Definition 4 (The logic). Let SNG be the smallest set of formulas containing 
all of the above axiom schemata and closed under application of the following 
rules: 



(modus ponens) — 
(□ -necessitation) 



(NAME stat ) 



0 



— > 0, a 

~0 

a 

□a 

0 



(A'-necessitation) 
(A -necessitation) 

(NAME sets ) 



a 

~Ka 

a 

Aa 

0 



(AT-enrichment) 
(□- enrichment) 
(A -enrichment) 



E(iAdA L(j A a)) —> 0 
E (i A A A La) — > 0 
E (i A A A 0(B A a)) — > 0 
E(z A A A Oa) — > (3 
E (i A A A E (j ABA a)) — » 0 



E(z A A A Ea) — > 0 

where a, (3 £ WFF, i,j £ N stat , A,B £ N sets , and j,B are ‘new’ each time. 



The reader can easily convince himself or herself that SNG is sound with 
respect to the class of all SSNs. But completeness too is yielded for this logic. 

Theorem 1 (Completeness). Every formida a £ WFF that is valid in all 
SSNs is contained in the logic SNG. 



The properties of the canonical model AIsng of SNG are exploited for the 
proof of Theorem 1. Since we put the main emphasis on decidability in this paper 
we explain only the starting point here and sketch the proceeding very roughly. 

First, the part of AIsng accessible from a distinguished maximal consistent 
set (which is determined by a given non-derivable formula) has to be named, 
and all existential demands concerning the modalities have to be realized. To 
this end, call a maximal consistent set s of formulas 

— named iff s contains some i £ N sta t and some A £ N sets , and 

— enriched iff 

1. E(z A A A La) £ s implies E(iAdA L(j A a)) £ s for some j £ N sta t, 

2. E(z A A A Oa) £ s implies E (i A A A 0{B A a)) £ s for some B £ N sets , 
and 

3. E(i A A A Ea) £ s implies E (i A A A E (j ABA a)) £ s for some j £ N stot 
and B £ N sets . 

Let N stot and N sets be two denumerable sets of new symbols, and WFF the 
set of formulas extended accordingly. Then we obtain the following Modified 
Lindenbaum Lemma. 



Lemma 1. Every maximal consistent set s C WFF can be extended to a named 
and enriched maximal consistent set s C WFF. 
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Furthermore, the following Existence Lemma can be proved for the structure 

Jvi of which the domain D consists of all named points that are reachable (via 
the canonical accessibility relations) from s and the relations are the induced 
ones. 

Lemma 2. Let V £ {L, O, E}. Assume that s £ D contains the formula Va. 
Then there exists some t £ D which is accessible from s with respect to V and 
contains a. 

Both lemmata can be proved with the aid of the new rules (among other 
things) . 

Now, the axioms of the second group force a set space structure already on the 
model M. Moreover, the third group of axioms guarantees that the modalities 
behave correctly as set space modalities there. Thus we get in fact ‘canonical’ 
completeness of the system, via an appropriate Truth Lemma. 

And we obtain even more. The fact that we are dealing with named objects 
enables us to extend the completeness proof to other classes of set spaces simply 
by adding a suitable defining correspondent. In this way we get, eg: 

Theorem 2 (Extended completeness). Let S be the formida schema from 
Proposition 1.1. Then the system SNG + S is sound and complete with respect 
to the class of all separated set spaces. 

A corresponding result holds for connected frames, and for other classes of 
set frames, too. 



4 Decidability 

Subsequently it is shown that SNG is a decidable set of formulas. As a prepara- 
tory step we must consider a class of auxiliary Kripke structures which are a bit 
involved. 

Definition 5 (Cross axiom models with names). A quintupel 



m := w. 



is called a cross axiom model with names ( or, in short, a CMN ), iff the following 
conditions are satisfied: 

— W is a non-empty set, 

— the relation — » C W x W (belonging to I\ ) is an equivalence, the relation 

C W x W (belonging to O) is reflexive and transitive, and the relation 
— 1 (belonging to A) is universal, 

— there is some w £ W such that W = {v \ (w,v) £ (— ->U -^->)*}, 

— for all u,v,w £ W such that u —> v — —> w there exists t £ W such that 

l o 

u — > t — > w , 



v 
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— V : PROP UNstat UN se ts — » V{W) is a mapping such that 

• for all c € PROP U N stat and it, v £ W satisfying u — > v it holds that 
u £V(c) iff v £V (c), 

• the intersection of V (i) with any — -equivalence class is either empty 
or a singleton set for every i £ N sta t, and 

• the set V (A) equals either 0 or a unique — » -equivalence class for every 
A £ N sets . 

The term ‘cross axiom model’ refers to the fourth item above and origi- 
nates from [4] . It is shown there that the basic logic of set spaces is sound and 
complete for interpretations in cross axiom models (without names), and that 
a corresponding finite model property is satisfied (though that logic lacks the 
finite model property with respect to set spaces) . 

We would like to establish the finite model property of SNG with respect to 
CMNs. However, not every CMN validates necessarily all of the above axioms. 
But, for a start, we get at least: 

Proposition 2. Apart, from, possibly, Axioms 15 and 16 each of the above 
schemata is valid in every CMN. 

Proof. As we are dealing with usual Kripke models presently, names of states 
and sets are treated like proposition variables. I.e., we have that 991, m |= c : 
<=>■ w € V(c), for all points in of 071 and c € PROP U N s t at U N sets . Now the 
verification of the axioms is rather straightforward. 

By way of example we prove the validity of Axiom 14. Suppose that there 
is a point in of 991 and an instance A (A A La — > L/3) V A (A A L/3 — > La) of 
that schema such that 911, in A (A A La — > L/3 ) V A (A A L/3 — > La) . Then 
991, in 1= E (A A La A ~>L/3 ) A E (A A L/3 A ~>La) . Consequently, there exist ini , m 2 
such that 991, W\\= A/\ La A K~>/3 and 991, in 2 \= A A L/3 A K~>a. As 991, mi \= A 

and 991, in 2 |= A we conclude that mi — w 2 . Thus 991, in 2 |= K~<(3 because 

991, mi |= and A i s transitive. However, this contradicts the fact that 

991, in 2 |= L/3. Our supposition is, therefore, false; i.e., Axiom 14 is valid in 991. 

We call a CMN 991 good, iff all the axioms are valid in 991. We want to show 
now that SNG satisfies the strong finite model property (cf [6], Def. 6.6) with 
respect to the class of all good CMNs. With that the desired decidability of 
SNG follows, using [6], Tlr. 6.7. 

To establish this finite model property we use the method of filtration. So, 
let a £ WFF be a consistent formula for which we want to find a model of size 
at most /( |a|), where / is some computable function and a denotes the length 
of a. Moreover, let sf(a) be the set of all subformulas of a. We construct an 
appropriate filter set £ via the following sets of formulas. We first let 

£ 0 := sf(a) U {CHA | A £ N sets n sf(a)}, 

and secondly := {— >/3 | (3 £ £q}- Then we take the set £' of all finite 
conjunctions of pairwise distinct elements of AgU JEN Finally, we close £' under 
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single applications of the operator L. Let £ be the union of all these intermediate 
sets of formulas. Note that £ is finite and subformula closed, and 2 C 'I“I is an 
upper bound of the cardinality of £ (for some constant c). 

Let C be the submodel of the canonical model generated by a maximal con- 
sistent set containing a. Moreover, let the Kripke model 

W:= 

be obtained from C as follows: 



— W is the filtration of the carrier set of C with respect to £, 

— — and — are the smallest filtrations (cf [6], p. 79) of the accessibility 
relations of C belonging to the respective modalities with respect to £, and 

— V is induced by the canonical valuation. 



Then, exploiting the structure of the filter set £ and the minimality of the 
filtrations we get the following crucial proposition. 



Proposition 3. The just defined model 9JT constitutes a filtration of C. More- 
over, adjusting the valuation V suitably, SOT can be turned into a good CMN SOT' 
which is semantically equivalent to SOT with respect to a. 



Proof. The first assertion of the proposition is quite obvious. However, we intro- 
duce some notations for later purposes. As is well-known, the domain kb of SOT 
consists of certain equivalence classes. Let us make explicit the corresponding 
equivalence relation. For all s,t £ C, where C is the domain of C, we define 
s ~ t : <==>■ snr = t n r, and we let s denote the ^-equivalence class of s. 
I.e., W = {s | s € C}. We use , -JU , and Vc, to denote the accessibility 

relations and the valuation of C, respectively. Then, 



s — t •<==>■ 3 s' £ s, t' € t : s' -jjA t' 

holds by definition (correspondingly for the other modalities). Moreover, V sat- 
isfies 



s £ V(a) s £ Vc (a) , for all s £ C and a £ (PROP U N stat u N sets ) n p. 

This explains how the valuation V of SDT is ‘induced’ by Vc- 

Now we prove the second assertion. To this end we modify V in the following 
way. We let 

V '( a \ . = [ V ( (J ) ii <t £ r 

' ' (0 otherwise, 

for all a £ PROP U N stat U N sets . Then we define 

3JT' := (W, , V 7 ) . 

With that we go successively through the items of Definition 5. It follows from 
[4], 2.10, that — is an equivalence, is reflexive and transitive and the cross 
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property holds 5 ; in addition, the rigidity of the proposition variables (as stated 
in the first condition of the last item of Definition 5) is satisfied for cross axiom 
models without names already. 

Since C is generated we conclude that is universal (by using Axioms 18 

- 21). Thus is universal as well. Moreover, Axiom 22 gives us the validity 
of item 3 for C, hence also for 9Jt'. 

The rigidity of the names of states follows in the same manner as the rigidity 
of the proposition variables (with the aid of Axiom 11 instead of Axiom 6). 

Suppose now that i £ N s t a t, s,t £ V'(i ) and s —>t. From this assumption 
we conclude that i £ T. Thus s,t £ Vc(i), and there are s' £ s and t' £ t such 
that s' -^A t' . Furthermore, i £ s' PI t ' . With the aid of Axiom 12 we get that 
s' = t' . Therefore, s = t, as we wanted to show. 

Finally, let s, t £ V'(A) for some A £ N sets . Then, an argument similar to the 
one just given shows that s -^At. (Axiom 14 has to be used for that, actually.) 

The denotation of A is, therefore, contained in a single —^A -equivalence class, 
say the class of s. But since s then contains A , we infer from this that 9ft', f |= A 
holds whenever s —At is valid (by utilizing Axiom 13). Thus the denotation of 
A equals the class of s, as desired. 

As we have that 9Jl,s |= a 4=> 9Jt',s |= a for all s £ W (since both 
structures are filtrations of the same model), it remains to be proved that 9Jt' is 
good. 

First we show that Axiom 16 is valid in 9Jt'. So, let w £ W and asssume 
that 9Jl',w 1= KOA. Then, for all u £ W such that w — ^A u there exists v u £ 

W satisfying u —> v u and 9 71', v u |= A, i.e., v u £ V'{A). In particular, v w is 
contained in V'(A). Thus V'(A) ^ 0. This implies A £ T. 

Let s £ C' be a representative of w, i.e. w = s, and let t £ C' satisfy s -^A t. 

Then w —At, i.e., |= £>A. Since OA is contained in T due to the definition 

of this set, we infer OA £ t from that. As we have chosen an arbitrary t £ C' 
such that s ~^t we conclude that KOA £ s. From Axiom 16 we obtain then 
A £ s. This implies 9Jl',w |= A. Therefore, Axiom 16 is valid in 91 V. 

Finally, the validity of Axiom 15 is to be established. To this end, assume 
that DJl',w [= K(OB — > OA) A LOB. From the second conjunct we can infer 
V'(B) ^ 0 in a similar way as above. It follows that B £ T. But the first conjunct 
implies then A £ T. 

Suppose towards a contradiction that Wl',w D(A — > LOB). Then there 
exists t £ W such that w -—>t and 9A',t |= A A ~^LOB. Due to the definition of 
the smallest filtration there are s' £ w = s and t' £t which are -^-connected: 
s' t'. Moreover, since both A and LOB are contained in r we have that 

A simplified proof of these facts was done in [14]. 
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A A -i LOB £ t', because of the well-known properties of maximal consistent 
sets. This means that 0(A A ~^LOB) £ s'. 

If we could prove that K{OB — > OA) A LOB £ s', then we will be done 
because all instances of Axiom 15 are contained in s'. Now, the second conjunct 
of this formula is clearly contained in s' since it is contained in T. As to the 
first conjunct, let u be an arbitrary element of C' such that s' ~^u. It suffices 
to show that ->0 B V OA £ u, i.e. , -> OB £ u or OA £ u. But both formulas 
are contained in T, and Wl',u \= ->0 B or 9 71', u |= O A is valid according to our 
assumption. Thus -> OB VO A £ u really holds. This proves the validity of Axiom 
15 in m'. 

All in all, we have proved Proposition 3 by that. 

Accordingly, a is satisfiable in a finite model of the axioms, of which the size 
is in O ( The main result of the present paper can be inferred from this 
easily now. 

Theorem 3 (Decidability). The logic SNG is decidable. 

As to the complexity of SNG, the proof of Theorem 3 yields obviously NEX- 
PTIME as an upper bound of the corresponding satisfiability problem. We be- 
lieve that it is possible to force this bound down to EXPTIME. On the other 
hand, [15], Theorem 4.5, gives us some reasons for suspecting that this problem 
is EXPTIME-hard. However, we do not know the exact complexity up to now 6 . 

5 Further Results and Concluding Remarks 

In this section we compare our approach with other combined hybrid logics of 
knowledge or topology. Moreover, we solve an open decidability problem for one 
of these systems. Finally, a short summary of the present paper is given. 

Though topologic supports a modal treatment of knowledge for as diverse 
contexts as, eg, topological spaces and branching time structures, cf [16] and [17], 
the underlying language lacks expressive power in other areas of application. Eg, 
linear time structures cannot be dealt with accordingly. Thus the language has 
to be strengthened. It turns out that hybrid means can help a lot here. 

In usual hybrid logic one has nominals acting as names of states to hand, 
among other things. Furthermore, a one-place satisfaction operator comes 
along with every nominal i. This operator enables one to evaluate a formula 
at the denotation of i. As stated above already, right after Definition 2, it is 
true that satisfaction operators accompanying names of states cannot be added 
consistently to the language of topologic. However, by naming neighbourhood 
situations this works well, actually, and, eg, linear time structures can then be 
captured; cf [18] and [8]. 

However, we were not content with this because of our further-reaching topo- 
logical requirements. Note that still none of the fundamental notions introduced 



Note that we do not know the complexity of basic topologic either. 
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in Definition 3 can be specified by means of the language naming neighbourhood 
situations. Thus we gave up that ‘strict’ hybrid approach and turned to the one 
presented here, which follows in a sense the sorting strategy from [5], Sec. 7. 
The new system proves to be very flexible, reflects clearly the dependence of 
properties on points and sets, respectively, and comprises the previous one with 
regard to expressiveness. Furthermore, by a suitable reduction argument we can 
prove that the earlier system is decidable. 

Theorem 4 (Decidability of orthodox hybrid logic). Letting nominals de- 
note neighbourhood situations, the corresponding hybrid logic of set spaces is 
decidable. 

Proof. First we revisit briefly the hybrid logic of set spaces considered in the 
papers cited above. All notations which are not new are kept from the previous 
sections of the present paper. 

The syntax of that ‘orthodox’ hybrid language is defined by the rule 

a ::= p | n | ~<a | a A (3 \ Ka | Do | @ n a, 

where p £ PROP and n € NNS; the elements of the latter set of symbols are 
called names of neighbourhood situations , and PROP and NNS are assumed to be 
disjoint. Moreover, @ n denotes the satisfaction operator belonging to the name 
n £ NNS. Finally, a special name no £ NNS is distinguished in advance. 

Hybrid set spaces are based on set frames (X, O) in the usual way, i.e. , by means 
of a hybrid valuation V : PROP U NNS — * V(X) UAf. We have, in particular, 
that V(n) £ AT for all n e NNS, and V (no) = x,X for some x £ X. 

Due to this restricted interpretation of no we are compelled to change both 
the language underlying SNG and this logic slightly. A special set name Y has 
to be distinguished, which always denotes the domain X. Moreover, Axiom 22 
has to be replaced with EY A (Y A Ea — > LOa) . The reader can easily check that 
Theorems 1-3 hold for the resulting variant, SNG', too. 

Let SH be the set of all formulas that are valid in every hybrid set space. 
By reducing the SH-satisfiability problem to the SNG'-satisfiability problem 
we prove now that SH is decidable. In fact, this follows easily from Theorem 3 
after a successful reduction. 

By induction on the structure of formulas we define a function T translating 
every hybrid formula into a formula of the comparison language. To this end 
we assign injectively a pair i n £ N stat and A n £ N sets to every n € NNS; in 
particular, A no = Y. Then we let 



Tip) 


= P 


T( n) 


— in A A n 


Tha) 


= -r(a) 


T(a A /?) 


= T{a) A T(/3) 


T(Ka) 


= KT(a ) 


T{Da) 


= DT(a) 


T(@ n a) 


= E (i n A A n A T(a)) 
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for all p € PROP, n G NNS and formulas a,/3 of the source language. T is 
obviously a computable function. 

Now we take any hybrid formula a. Let ni , . . . , n n be the names of neigh- 
bourhood situations occurring in a. Then we have that 

(*) a is satisfiable 4=4> T(a) A E (i n A A n ) is satisfiable 

with regard to the respective class of models. 

In fact, an SSN Mjj satisfying the second conjunct on the right-hand side 
of (*) can easily be assigned to any hybrid set space M. based on the same 
frame, and vice versa, so that each of the following assertions can be proved by 
induction on a : 

x, u l=XT a x ’ U l=Atjcr T ( a ) and x > U l=M T ( a ) <s=4> x i U \=m m a > 

where x, U is any neighbourhood situation of the underlying frame. In this way, 
(*) is yielded. 

This concludes the proof of Theorem 4. 

Note that the decidability results contained in [18] and [19] concern only 
special classes of hybrid set spaces. The general case stated in Theorem 4 could 
not be established in a more direct way up to now. 

It should be remarked that a (usual) hybrid extension of the classical topo- 
logical semantics of modal logic (going back to [20]) was briefly considered in 
[21] (with regard to expressiveness). 

Just to sum up, in the present paper we developed the fundamental matters 
of a logic, SNG, for set spaces with names. It turned out that this system is 
sufficiently expressive as well as computationally well-behaved to serve as an 
adequate basis for both reasoning about knowledge and specifying topological 
properties. Our results (concerning expressive power, completeness and, mainly, 
decidability) and a comparison to other approaches showed that SN G is a rather 
satisfactory system of that kind. However, some open problems for other inter- 
esting classes of set spaces seemingly cannot be solved within the framework 
of SNG, eg, the question of decidability for the logic of directed spaces (which 
model ‘converging’ knowledge acquisition procedures); cf [22]. 
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Abstract. This paper shows how systems can be built from their com- 
ponent parts with specified sharing. Its principle contribution is a mod- 
ular language for configuring systems. A configuration is a description 
in the new language of how a system is constructed hierarchically from 
specifications of its component parts. Category theory has been used to 
represent the composition of specifications that share a component part 
by constructing colimits of diagrams. We reformulated this application of 
category theory to view both configured specifications and their diagrams 
as algebraic presentations of presheaves. The framework of presheaves 
leads naturally to a configuration language that expresses structuring 
from instances of specifications, and also incorporates a new notion of 
instance reduction to extract the component instances from a particular 
configuration. The language now expresses the hierarchical structuring 
of multi-level configured specifications. The syntax is simple because it 
is independent of any specification language; structuring a diagram to 
represent a configuration is simple because there is no need to calculate 
a colimit; and combining specifications is simple because structuring is 
by configuration morphisms with no need to flatten either specifications 
or their diagrams to calculate colimits. 



1 Introduction 

Large complex systems are put together, or configured, from smaller parts, some 
of which have already been put together from even smaller parts. This paper 
presents a modular language that expresses the hierarchical structuring of a 
system from specifications of the component parts. We review briefly the math- 
ematical framework for configuration in order to focus on the constructs of the 
language. Systems configuration involves specifying each of the components of 
the system as well as the relationship of sharing between these components. The 
structure of the system is therefore expressed directly and mathematically by the 
syntax of the configuration language, while the history of system construction is 
kept at a second level of mathematical structure by the accumulation of many 
levels of configured specifications as configuration proceeds. We propose a new 
and simple concept of ‘instance’ of a specification to manage the complexity of 
large systems which may require many instances of their component parts. 



C. Rattray et al. (Eds.): AMAST 2004, LNCS 3116, pp. 196-210, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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1.1 The Development of the Work 

The motivation for our work has been to contribute to research into the mod- 
ularization of systems. Our aim has been to design a language for configuring 
systems that is easy to use and involves concepts that should seem natural to 
software engineers. The language is simple because no assumptions are made 
about the underlying logic for specification. In earlier work we used the term 
‘module’ to mean a ‘uniquely named instance of a specification’. We now use the 
term ‘instance’, in order to avoid confusion with the use of ‘module’ to mean 
a ‘composite structure wrapped up to form a single unit’. This latter use of 
‘module’ is closer to the meaning of a configured specification. 

Mathematically we were influenced by Burst all and Goguen, who gave a cat- 
egorical semantics for their specification language Clear, in [2,3]. Categorical 
colimits were used for building complex specifications in [3,12]. We followed 
Oriat [9] in using colimits to express configuration in a way that was indepen- 
dent of any particular specification language. Oriat compared two approaches, 
one using diagrams and the other using a calculus of puslrouts. Both in effect 
described the finite cocompletion of a category C of primitive (unconfigured) 
specifications. 

In [13] we used instead finitely presented presheaves. This is a mathematically 
equivalent way of making a cocompletion, but leads to a different notation that 
very naturally describes how a configuration specifies instances of the compo- 
nent specifications, brought together with specified sharing of subcomponents. 
In flavour it is not unlike object-oriented languages, with the relationship be- 
tween instances and specifications being analogous to that between objects and 
classes [8, 1] (though [13] points out some respects in which the analogy cannot 
be pushed too far). 

As a simple example of our notation we describe, in this paper, a shop in 
which there are two counters sharing a single queue in which customers wait for 
whichever counter becomes available. We also discuss how the abstract preslreaf 
structure is a means for describing what ‘subcomponents’ are, with a categorical 
morphism from one specification, S , to another, T, representing a means by 
which each instance of T may be found to bring with it an instance of S — for 
example, how each shop counter has a queue associated with it. 

However, the approach of [13] was entirely ‘flat’, in that each configuration 
was described in terms of its primitive components. A more modular style of 
configuration, developed in [6], allows multi-level configuration of either primitive 
or previously configured components. The structure of the categorical framework 
is simply a hierarchy of categories, in which each configuration belongs to a 
level and is represented by a structured categorical diagram. Morphisms, as 
simple implementations between configured specifications, are allowed to cross 
the levels of the hierarchy. There is a notion of assignment between the instances 
of specifications, and in addition proof obligations are discharged. A case study, 
of configuration up to four levels, illustrates the expressiveness of the language. 
The category theory becomes somewhat deeper, with the interesting possibility 
of incorporating recursively defined configurations, and is still to be worked out 




198 



Gillian Hill and Steven Vickers 



in detail. However, the configuration language is subject to only two simple 
modifications, and it is the aim of this paper to describe them. 



1.2 The Structure of the Paper 

In Sect. 2 the key idea of ‘composites as presheaves’ is introduced as an alter- 
native to the established work on ‘composites as colimits’. Presheaves provide a 
firm mathematical basis for the configuration language: preslreaf presentations 
correspond to the components of a configuration and the relationship of shar- 
ing a common component; presheaf homomorphisms correspond to morphisms 
between configurations. In Sect. 3 we review the configuration language of [13]. 
Mathematically, it is formally equivalent to presenting presheaves by generators 
and relations, and that provides a well defined abstract semantics. Specification- 
ally, however, one should read each configuration as specifying components and 
sharing. In Sect. 4 it is extended to a modular language for multi-level configura- 
tion, with two new language constructions (‘basic up’ morphisms, and ‘indirect’ 
morphisms). We present the case study briefly in Sect. 5, and in Sect. 6 we draw 
conclusions. 



2 Composite Specifications as Presheaves 

We gave the theoretical framework chosen for configuration in “Presheaves as 
Configured Specifications” , [13] . Most of the technical details of the paper are due 
to Steven Vickers. Configuration builds composite specifications as presheaves 
because they express colimits in category theory. Previous research has viewed 
composite specifications as colimits; the approaches have varied, however, in 
the choice of a category with appropriate colimits. For example, the pioneering 
work by Burstall and Goguen on expressing the structuring of specifications by 
constructing the colimits of diagrams, in [2,3], was continued in the algebraic 
approach to specification [5,4, 10] and also in proof-theoretic approaches [7, 11]. 
All these research methods depended on the different specification logics that 
were used, because they constructed colimits over some cocomplete category of 
specifications. 

A contrasting aim of configuration is to separate the specification logic of 
the primitive (unconfigured) specifications from their configuration. Colimits 
are expressed in a category of configurations which is a free cocompletion of 
the category of primitive specifications. There are no assumptions about the 
underlying logic. This more general approach allows the category of primitive 
specifications to be incomplete. 

We followed Oriat [9] in working more generally. She models the composi- 
tion of specifications by working within an equiv-category of diagrams, which 
is finitely cocomplete. Her equiv-category of base specifications need not be 
complete, however. Oriat’s constructions on diagrams are shown in [13] to be 
mathematically equivalent to the construction of presheaves in configuration. 
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2.1 Presheaves 

The mathematical theory of presheaves provides an alternative construction to 
Oriat’s cocomplete category of diagrams for modelling the composition of dia- 

^-7°P 

grams. Formally, the category Set is the category of presheaves over a small 
category, C. It follows that a presheaf , ’ as an object in the category, is a functor 
from C op to Set, and a presheaf morphism is a natural transformation from one 
presheaf to another. The category Set c P is a free cocompletion of C. The theory 
is difficult, and it is understandable that its suitability for the practical appli- 
cation of building specifications might be questioned. There are, however, three 
main reasons why presheaves express configurations precisely: when presented 
algebraically, a presheaf expresses the structure of a configuration; a presheaf 
over C is formally a colimit of a diagram in C; for each morphism in C, a presheaf 
presentation provides a contravariant operator from which instance reduction is 
defined between configurations. 

/°°P 

The fact that Set is cocomplete means it has all small colimits. Intuitively, 
the fact that it is freely cocomplete means that it contains all the colimit objects 
and the morphisms to the colimit objects, but no more. Although expressing 
colimits by presheaves is more complicated theoretically than by just using di- 
agrams, presenting presheaves algebraically simplifies the theory so that it is 
appropriate for configuration. 



2.2 Presheaves Presented Algebraically 

The key idea is that using generators and relations algebraically to present a 
presheaf corresponds directly to specifying components and the sharing of sub- 
components in a composite system. This correspondence gives a direct physical 
interpretation to the configuration language. 

Presheaves are presented, in detail in [13], as algebras for a many-sorted 
algebraic theory PreSh(C). The sorts of the theory are the objects of C, and for 
each morphism u : Y — > X in C, there is a unary operator oj u : X — > Y. 

The definition of an algebra P for PreSh(C) gives: 

— for each object X of C, a set P(X), the carrier at X\ 

— for each morphism u : Y — > X, an operation P(u) : P(X) — * P(Y) (written 
X l— > ux). 

Algebras and homomorphisms for PreSh(C) are equivalent to presheaves and 
presheaf morphisms. The correspondence with configurations becomes apparent 
when presheaves are presented, as algebras of the algebraic theory PreSh(C), by 
generators and relations. We give only the main points of the correspondence: 

— A set of generators (with respect to PreSh(C)) is a set G equipped with 
a function D : G — » ob C, assigning a sort to each generator in G. In 
configuration the generators stand for instances of specifications. Instead 
of denoting the sort of a generator by D{g) = X, writing g : X is more 
suggestive of declaring an instance of the specification X. 
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— If G is a set of generators, then a relation over G is a pair (ei, e2) (written as 
an equation ei = e2) where ei and e2 are two expressions of the same sort, 
X , say. In configuration, the expressions will describe instances of the same 
specification. Expressions are built out of G by applying a unary operation 
that corresponds to a morphism. Relations can be reduced to the form ug\ = 
ug 2 . 

— A presentation is a pair (G,R) where G is a set of generators and A is a 
set of relations over G. The preslreaf that is presented by (G, R) is denoted 
PreSh(G | R). Presheaf presentations correspond to configurations. 

Example 1 . Suppose C is the category with two objects, X and Y, and one 
morphism u : X — > Y (and two identity morphisms). A presheaf P over C is 
a pair of sets P(X) and P{Y) equipped with a function, the u operation from 
P{Y) to P{X). Suppose P is presented by generators 51 and g 2 (both of sort 
Y) subject to ugi = ug 2 . This is denoted by: 

P = PreSh(<7i, g 2 : Y \ ug\ = ug 2 ) 

Then P(Y) = {51,52}, and P(X) has a single element to which u maps both 51 
and g 2 . In configuration this single element is the reduction by u of 51 and g 2 . 

An advantage of the correspondence with presheaves for configuration is that 
instead of describing an entire preslreaf, by objects and morphisms, enough ele- 
ments are presented to generate the rest algebraically. Although diagrams pro- 
vide a simpler way of describing colimits than preslreaves, the presentation by 
generators and relations is more natural than diagrams for expressing the con- 
figuration of components (by generators) and the sharing of components (by 
shared reducts). 



2.3 Primitive Specifications 

Configuration is over an arbitrary base category C. The objects of C are primitive 
(unconfigured) specifications that, for instance, may be named after the theory 
presentations in the category Tlrpr, but are without their logical properties. For 
example, a theory presentation for a queue could be named as a primitive spec- 
ification Queue in C. The morphisms in C are named after the interpretations 
between theory presentations in mor Tlrpr. The category C is the working cat- 
egory for configuration: its objects are those specifications that represent the 
basic components of the particular system to be configured. The structure of C 
is not restricted by making it cocomplete; colimits are constructed as preslreaves 
over C in a free cocompletion. This means that preslreaves express configura- 
tion from primitive specifications without referring to their logical properties. 
Already configuration is shown to contrast with other approaches, such as [ 11 ], 
that work with a category of specifications over some chosen logic; preslreaves 
are colimits whereas other approaches construct colimits of diagrams. 
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3 The Language for Flat Configurations 

This section presents the language of [13], expressing the flat configuration of a 
system from primitive component parts. It assumes some fixed small category C, 
whose objects stand for the primitive specifications, and constructs a category 
Config(C) whose objects stand for the configured specifications. 

It is also important to understand the role of the morphisms. If / : S — * T 
is a morphism (in C or in Config(C)), then it is intended to be interpreted as 
showing a way by which each instance of the specification T can be ‘reduced to’ 
an instance of S . If IT is a T instance, then we write / IT for the correspondingly 
reduced S instance. A typical example of what ‘reduced to’ means is when each 
instance of T — that is to say, each thing satisfying the specification T - 
already contains within it (as a subcomponent) an instance of S. There may be 
different modes of reduction. For example, if each T instance contains two S 
instances in it, then there must be two morphisms S — » T. 

3.1 Flat Configurations 

The configured specification, S , structured from instances of primitive specifica- 
tions, could be expressed by: 

spec S is 

components 

ISi : Si ; 

IS, : S z ; 

IS„ : S n 

equations 

el: / ISi = g IS j 



endspec 

The relation el states the equality between the two reducts, instances of the 
primitive specification T that is the common source of the morphisms / to 5) 
and g to S v The specification S', , an object in C, only becomes a specification in 
the flat world Config(C) when it is configured as conf-Si and declares a formal 
name for a single instance of S t : 

spec conf-Si is 

components 

Is, : S t 

endspec 

Intuitively, conf-Si puts a wrapper round the named instance Ig, of 5). 
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Example 2. A system of counters in a post office has queues of people waiting to 
be served. Let Counter and Queue be specifications whose instances are actual 
counters and actual queuing lines. Each counter has a queue, and this instance 
reduction from Counter instances to Queue instances is to be represented by a 
morphism i : Queue — ■> Counter. The configured specification that expresses the 
sharing of that queue by two counters in a post office is presented as: 

spec Sharing Of Queue is 
components 
Ci : Counter ; 

C2 : Counter ; 
equations 
el: i Ci = i C2 
endspec 

Although the instance of the shared queue is not declared in this general 
form, the expressions i Ci and i C2 of el each describe the instance reduct for 
the specification Queue. The specification conf-Counter could be configured in 
Config(C) by ‘wrapping it up’ as: 

spec conf-Counter is 

components 

IC : Counter 

endspec 

3.2 Morphisms between Flat Configurations 

A morphism from one configuration, S , to another, T , is again going to rep- 
resent instance reduction, showing how any instance of T can be reduced to 
an instance of S . We shall view this as implementation. Any T instance must 
contain all the components of S, with the correct sharing, and so provide an 
implementation of the specification S . The implementation is expressed by in- 
terpreting the individual components of S in T according to the assignments I 
1 — > / J, for I, a component of S , and J, a component of T . In addition a proof 
must also be given that the assignments respect the equations in S . The syntax 
for a configuration morphism as an implementation must therefore include both 
assignment of components and proof that equations hold. That proof, that is 
fundamental to the formal building of a system from its components, is made in 
the syntax of the configuration language using equations in T in a forwards or 
backwards direction. 

Example 3. (from Ex. 2 ) We define two morphisms, / and <7, from the configura- 
tion conf-Counter to SharingOf Queue, and a morphism, h, from Sharing Of Queue 
to conf-Counter. f and g pick out the two counters Ci and C2 of SharingOf Queue, 
thus showing two ways by which a Sharing Of Queue instance can be reduced to 
a conf-Counter instance, h describes a degenerate way in which single conf- 
Counter instance can be used to provide a Sharing Of Queue instance, with the 
single counter doing all the work for two counters. 
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implementation/: conf-Counter 

— » Sharing Of Queue 

IC e- > id Q oun t er Ci; 

endimp 

implementation g: conf-Counter 

— •> Sharing Of Queue 

IC i— > id (j oun f er C2; 

endimp 

implementation h: Sharing Of Queue 
— > conf-Counter 

Ci id(j oun t er IC; 

C2 1— > id Counter IC; 

To check el of Sharing Of Queue: 

i Ci l— * * ; ^Counter ^ 

* 1 i C 2 

endimp 



The composition of morphisms is expressed by the notation ; . The proof that 
the equation el : i Ci = i C2 in Sharing Of Queue is respected by the assignment 
of instances to conf-Counter is simple. The symbol 1— ► denotes the assignment 
from the instance on the left hand side of el of Sharing Of Queue to the instance 
of conf-Counter. Finally the symbol <— 1 denotes the assignment from i C2 on the 
right hand side of el in Sharing Of Queue to i ; id Counter IC in conf-Counter. 

The morphism h makes the point that the mathematics of colimits as used 
for specification can specify equalities but not inequalities. 

4 The Language for Multi-level Configurations 

The aim of this section is to extend the configuration language by modularity to 
express the hierarchical structuring of multi-level configurations, independently 
of any logic. The syntax of the modular configuration language directly expresses 
the structure of a system, so that the user of the configuration language is able 
to record the history of configuration in easily understood amounts. 

Configuration offers a semantics for the structuring of specifications which is 
new in two respects. The first is that flattening can be avoided because config- 
urations are isomorphic to their flattened form. The second respect is that the 
manipulations do not rely on a flattened form even existing. The language allows 
morphisms to be defined with ‘relative’ flattening down a few levels in the hierar- 
chical configuration but without necessarily reaching a primitive level. To match 
this, [ 6 ] does not construct the mathematical workspace inductively, starting 
with the primitive level and working up, but instead offers an axiomatic ap- 
proach that identifies the structure needed to interpret the language constructs. 
Potentially then, the workspace can contain configurations of infinite depth and 
give meaning to recursively defined configurations. 
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4.1 The Objects and Morphisms in the Configuration Workspace 

Providing a new mathematical semantics for structuring multi-level specifica- 
tions in a categorical workspace leads to a new engineering style of manipulation 
for the specifications. The primitive and configured specifications are collected 
together in a single category and configuration becomes a construction that can 
be applied with arbitrary objects and morphisms. Since S and conf-S are now 
objects in the same category they are assumed to be isomorphic, and this isomor- 
phism leads to the extra syntactic features of basic up and indirect morphisms 
in the multi-level language. 

Objects are either primitive or configured. 

Primitive objects are drawn from a category C. 

Configured objects use the keywords spec and endspec as before to put to- 
gether components with sharing. However, now their component specifications 
may themselves be either primitive or configured, possibly with some of each. 
Morphisms may be defined between any objects in the workspace, and are 
needed to construct new objects or to prove that objects are equivalent. Again, 
they represent a contravariant notion of instance reduction, that gets an instance 
of the source specification from an instance of the target. 

Primitive morphisms from C are between primitive specifications. 

Configuration morphisms are defined as in Sect. 3. 

However, new morphisms are needed to make any configuration S isomorphic 
to the configured specification conf-S that declares an instance of S. 

4.2 Basic Up Morphisms 

These morphisms arise from the need for a morphism from S — > conf-S. Suppose 
Is is declared as the component in conf-S. Our syntactic device is to use that 
instance name also as the name of the morphism, Is : S — > conf-S. If IS: S is a 
component in a configuration T, then as in Sect. 3, we can define a configured 
morphism 

implementation h: conf-S — > T 
Is > ids IS 

endimp 

The morphism h can be composed with the isomorphism S — > conf-S to get 
a morphism / from S to T. Again we apply the device of using the instance 
name IS as the name of this composite morphism, IS : S — > T, and this is the 
most general form of what we shall call a basic up morphism. Note that S may 
be either primitive or configured. 

4.3 Indirect Morphisms 

These arise from the morphism conf-S — > S and are defined as indirect imple- 
mentations that use the keyword given. This syntax provides a formal name for 
an instance in the target specification of the morphism: 
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implementation/: T —> S 
given instance IS: S 



endimp 

Here the middle, omitted, part is just the usual format (as before) for the 
body of a configuration morphism. The instance name provided can be taken as 
defining an anonymous configuration which is isomorphic to confS: 



spec is 

components 
IS : S 
endspec 

The indirect definition of / supplies the data for a morphism from T to this 
anonymous configuration. This is then composed with the isomorphism confS 
— » S to give the indirect morphism f : T S . Again indirect morphisms arise 

from the need to have every S isomorphic to confS. The isomorphism confS 
— > S can itself be denoted using the ‘given’ notation. 

4.4 Morphisms between Multi-level Configurations 

We have defined morphisms from configured specifications to primitives. We also 
need to define them between configured specifications. 

Example f. (from Ex. 2 ) Second level and first level configurations illustrate two 
ways of making a post office with three counters and one shared queue: 

spec ExtendedShop is 
components 
C1QC2 : Sharing Of Queue ; 

C3 : Counter ; 

equations 

el: i C3 = i ; Cj C1QC2 

endspec 

The morphism C\ is a basic up morphism. 

spec NewShop is 
components 
Ci : Counter ; 

C2 : Counter ; 

C3 : Counter ; 
equations 

el: i Ci = i C2 ; 
e2: i Ci = i C 3 
endspec 
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These configurations are isomorphic, but the isomorphism g: ExtendedShop 
— > NewShop cannot be defined except indirectly, with given. The syntax of the 
indirect implementation, g, also uses a keyword where to introduce a locally 
defined morphism, f: Sharing Of Queue — * NewShop. 

implementation g: ExtendedShop 
— * NewShop 

given instance INS: NewShop 
CiQC 2 ^ / INS ; 

C 3 ^ Qi INS ; 

where 

implementation /: Sharing Of Queue 
— » NewShop 

Ci h- Ci ; 

C 2 ^ C 2 ; 

To c/iecfc el of Sharing Of Queue : 
i Ci j Ci 

= * C 2 by el of NewShop 
H ! C 2 

endimp 

To c/iecfc el of ExtendedShop: 
i C 3 1— > * ; C3 INS 

= * ; Ci INS by e2 of NewShop 
= i ; Ci ; / INS 
< — 1 i ; Ci CiQC 2 
endimp 

The proof for equation el of ExtendedShop uses the fact that Ci INS = Ci ; / 
INS. This comes directly out of the definition of /, from Ci 1— > Ci» 

5 A Case Study 

We use the new configuration language in a case study, based on an example of 
Oriat’s [9], to express alternative configurations for the theory of rings. In [6] the 
aim of the case study is to compare Oriat’s method of composing specifications, 
by constructing the pusliouts of diagrams, with the method of configuration. 
Since in configuration both specifications and their diagrams express algebraic 
presentations of presheaves, and finitely presented presheaves express colimits, 
the need to construct pusliout diagrams is bypassed. Since equivalence between 
configurations can be proved textually, Oriat’s need to flatten diagrams (to con- 
struct their colimits) and to complete diagrams before normalizing them can 
also be bypassed. 

5.1 Building Flat Configurations from Primitive Specifications 

The theory presentations and theory morphisms that underly the primitive spec- 
ifications for the components used to configure a ring are expressed in the style 
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of Z schemas. As in Sect. 2.3 we use the name of each theory presentation, for- 
getting its logical properties, to identify a primitive specification. The simplest 
component of the mathematical structure of a ring expresses a single sort s. 



.Asort\s 



The schema Bin- op specifies a sort, also called s, and a binary operator op: 

Bin-op[s\ 

op : s x s — > s 



The theory morphism s : Asort — > Bin-op maps the sort of Asort to the sort 
of Bin-op. The schema for the structure of a monoid is: 

Monoid[s\ 

x : s x s — > s 
1 y s 

V x,y, z : s . (x x y) x z = x x (y x z) 

\/ x : s . 1 x x = x 
\/ x : s . x x 1 = x 



The theory morphism b : Bin-op Monoid maps the sort of Bin-op to the 
sort of the monoid, and the operator op of Bin-op to the operator x in the 
monoid. The theory presentation for an Abelian group is formed from Monoid 
by adding an inverse function and the property of commutativity for the binary 
operator, +. The theory morphism m maps the operator x of Monoid to the 
operator + of Abel- group and the constant 1 of Monoid to the constant 0 of 
Abel- group. 




Finally the schema Distributive specifies two binary operators that are re- 
lated by the property of distributivity. There are two morplrisms from Bin- op to 
Distributive: the morphism m+ maps op to +; the morphism m x maps op to x. 
The axioms for the distributive structure express both left and right distributiv- 
ity for x over +. 
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Distributive[s\ 

+ : s, s — > s 
x : s,s — > s 

Vi, y, z : s . x x (y + z) = (x x y) + (x x z) 
V x, y, z : s . (y + z) x x = (y x x) + {z x x) 



In the text of the configured specifications we use abbreviations for the in- 
stance names. Of four equivalent specifications for the flat configuration of a ring 
the following is the most compact: 

spec Ringl is 
components 
M : Monoid ; 

A : Abel-group ; 

D : Distributive ; 
equations 

el: b ; m A = m+ D ; 
e2: b M = m x D 

endspec 

The specification Ringl describes the sharing of the boolean operators ex- 
plicitly. The instance reduct b ; m A gives the binary operator for addition, 
derived by reduction from the instance A of Abel-group. The instance reduct b 
M is the operator for multiplication, derived by reduction from the instance M 
of Monoid. That is, el describes the sharing of the addition instance of Bin-op, 
and e2 describes the sharing of the multiplication instance of Bin-op. 

5.2 Natural Uses of Modularization 

In Oriat’s language of terms, all colimits of representative diagrams are puslrouts. 
In the configuration language, modularization is only used if required specifica- 
tionally: it is not imposed by puslrout terms. Configurations that correspond to 
Oriat’s modular constructions of a ring are built in [6]. Two of these are more 
natural because, although they are built by adding distributivity to a pseudo- 
ring, neither requires the construction of an extra configuration for the pair 
of binary operators. Together with the flat Ringl , we select these modularized 
configurations as the ideal configurations for a ring. R.ing4, a fourth-level specifi- 
cation, illustrates the flexibility of our language by expressing the sharing of each 
instance of the binary operator in an equation. The history of the configuration 
is presented first in the three lower-level configurations. 

spec Pair_Bin-op_and_Asort is 
components 
a : Bin-op ; 
m : Bin-op ; 

equations 

el: s a = s m sharing the instance s 

endspec 
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spec Pair_Bin-op_Asort_and_Monoicl is 
components 
M : Monoid ; 

ams : Pair_Bin-op_and_Asort; 
equations 
el: b M = m ams 

endspec 

spec Pair_Bin-op_Asort_Monoid_ancLAbel-group is 

components 

amsM : Pair_Bin-op_Asort_and_Monoid; 

A : Abel-group ; 

equations 

el: a ; ams amsM = b ; m A 

endspec 

spec Ring4 is 
components 

D : Distributive ; 

amsMA : Pair_Bin-op_Asort_Monoid_and_Abel-group ; 

equations 

el: m x D = m ; ams ; amsM amsMA ; sharing the instance m 
e2: m+ D = a ; ams ; amsM amsMA sharing the instance a 

endspec 

6 Conclusions 

We thank the reviewers for inspiring us to improve the paper. Our goal has been 
to introduce, independently of specification language, a modular configuration 
language that expresses the construction of large complex systems from their 
component parts, with specified sharing. We have already presented in [13] a 
configuration language based on components and sharing that is independent 
of specification language. It has an abstract semantics using presheaves that is 
mathematically equivalent to the diagrammatic approach of [9]. However, it is 
limited to flat configurations: it has no modularity and is unable to express any 
further structuring to multi-level configurations. The modularity here, avoid- 
ing the need to flatten structured specifications, has been achieved categorically 
in [6] by having explicit isomorphisms between unflattened configurations that 
would become equivalent when flattened. Linguistically it works by the use of 
two new constructions, the basic ups and the indirect configuration morphisms, 
whose interpretation provides those isomorphisms. Although the configuration 
language has been presented with a detailed case study in [6], more work is 
required on the semantics of the language. The need to avoid the absolute flat- 
tening of configured specifications to a primitive level suggests that a hierarchical 
workspace of infinite depth should be constructed with the potential to deal with 
recursively defined configurations. 
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Abstract. Proof reuse, or analogical reasoning, involves reusing the 
proof of a source theorem in the proof of a target conjecture. We have 
developed a method for proof reuse that is based on the generalisation - 
replay paradigm described in the literature, in which a generalisation of 
the source proof is replayed to construct the target proof. In this paper, 
we describe the novel aspects of our method, which include a technique 
for producing more accurate source proof generalisations (using knowl- 
edge of the target goal), as well as a flexible replay strategy that allows 
the user to set various parameters to control the size and the shape of the 
search space. Finally, we report on the results of applying this method 
to a case study from the realm of software verification. 



1 Introduction 

Formal methods provide the promise of software that is provably free of faults. 
To have confidence a method has been applied correctly, proofs associated with 
the method must be mechanically verified. For most applications, however, such 
mechanical verification is infeasible due to the amount of user interaction re- 
quired for even quite simple proofs. 

One way to reduce the cost of mechanical verification is to reuse an exist- 
ing proof, called the source proof, to help prove a target conjecture. Methods 
described in the literature work either by 

— verifying axioms used in the source proof for the domain of the target con- 
jecture (e.g. Kolbe and Walther’s Plagiator system [10]), or 

— using the structure of the source proof to construct a proof of the target 
conjecture, either at the object level (e.g. the work of Melis and Schairer [6]) 
or at the meta level (e.g. the Abalone system of Melis and Whittle [7]). 

In this paper we describe a method for proof reuse that makes use of the 
source proof structure at the object level. It is based on the two-phase paradigm 
[6, 7] that involves generalising a source proof to produce a proof schema that 
can then be replayed on a target conjecture. 

The paper is organised as follows. In Sect. 2 we introduce our case study - 
verifying the correctness of an algorithm for solving the Dutch National Flag 
problem - which we will use to demonstrate and evaluate our method. In Sect. 3 
we provide a brief overview of our basic generalisation - replay approach to reuse. 



C. Rattray et al. (Eds.): AMAST 2004, LNCS 3116, pp. 211-225, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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In Sect. 4 we build on these ideas by describing a new approach for dealing with 
situations in which the source proof schema does not match the target goal. 
Next, in Sect. 5 we outline a strategy that we have developed and implemented 
for replaying a source proof. The strategy is based on a mix of heuristics and 
practical experience with replaying actual proofs. Unlike the replay strategy of 
[6], we allow a general search at each step of the replay, rather than simply 
applying (after appropriate preparation) the tactic used at the analogous point 
in the search proof. This gives our strategy added flexibility but means we must 
control the size of the search space. In Sect. 6 we report on the results of applying 
our method to the Dutch National Flag problem. Finally in Sect. 7 we present 
our conclusions. 



2 A Case Study — The Dutch National Flag 

The specific software verification domain for which we have developed our reuse 
method involves proving the correctness of imperative programs using a Hoare- 
style logic [2]. One of the examples we have used, and the one to which we will 
refer throughout the rest of this paper, is Dijkstra’s Dutch National Flag Prob- 
lem [1], in which coloured array elements must be partitioned in accordance with 
the Dutch national flag (red followed by white followed by blue) . A standard so- 
lution described by Kaldewaij [5], shown in Fig. 1, uses a single loop to maintain 
three (initially empty) non-overlapping segments, each containing elements of 
one colour. The loop gradually increases the size of these segments until all the 
elements have been processed. 



|[ con N : int{A > 0}; 

var h : array[0..A) of [red, white , blue]; r, w, b :int 
r, w, b := 0, 0, N; 
do w ^ b — > 

Invariant = { 

{Vi:0<i<r:h.i = red ) A (V i : r < i < w \ h.i = white) A 
(V i : b < i < N : h.i = blue) AO <r<w<b<n} 
if h.w = red — * swap.h.w .r; r, w := r + 1, w + 1 
] h.w = white — > w := w + 1 
] h.w = blue — * swap.h.w.(b — 1); b := b — 1 
fi 

od 

{(V i : 0 < i < r : h.i = red) A (V i : r < i < w : h.i = white) A 
(V i : w < i < N : h.i = blue)} 

]| 



Fig. 1. A program written in the guarded command language for solving the Dutch 
National Flag problem 
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The proof of correctness of this program consists of a number of parts, some 
of which are quite easy to show, e.g. showing the assignments are type correct. 
However, in this paper we will focus on the longest (accounting for over half of 
the total user interactions) and most difficult part of the proof, which is showing 
the invariant predicate ( Invariant ) is maintained by each iteration of the loop. 
This requires showing that the combination of the invariant and the loop guard 
holds across each branch of the conditional statement, e.g. for the third branch 
(the Blue branch), this requires the following to be shown (we use the notation 
A — » B to mean that B holds under the assumptions A - our work is equally 
applicable to both natural deduction and sequent calculus theoreom provers): 

(V i : 0 < i < r : h.i = red) A (V i : r < i < w : h.i = white) A 

(V i : b < i < n : h.i = blue) A w A b A h.w = blue AO <r<w<b<n 

(V i : 0 < i < r : h(w, b — 1 : h.(b — 1), h.w).i = red) A 
(V i : r < i < w : h(w, b — 1 : h.(b — 1), h.w).i = white) A 

(V * : fo — 1 < i < n : h(w, b — 1 : h.(b — 1), h.w).i = blue) 

0<r<w<b — 1 < n 



To prove this, we need to show each conjunct of the right hand side holds 
given the assumptions on the left. For our purposes we will ignore the final 
conjunct (whose proof is not interesting) and concentrate on the first three, 
which we will subsequently refer to as Blue. 1, Blue . 2 and Blue . 3 (and similarly 
for the Red branch). We will also ignore the White branch since its proof is 
trivial. 



3 Proof Reuse — An Overview 

In this section we briefly outline our basic two-step generalisation replay model 
of proof reuse. In the generalisation phase, a proof schema of the source proof is 
constructed. The schema construction method involves reconstructing the source 
proof using a variable in place of the original source goal, and using generalised 
inference rules in which function symbols have been replaced with function vari- 
ables. Starting with a variable instead of the original goal allows us to generalise 
subterms in the goal that are not relevant to the proof - the variable is instan- 
tiated as part of the schema construction as necessary by the application of the 
generalised inference rules. Given a proof P, we write Schema(P) to denote the 
proof schema constructed from P . 

As an example, consider the following proof fragment P.1, taken from the 
proof of Blue. 1 (the proof is meant to be read down the page in a goal-directed 
fashion, child nodes are indented, multiple assumptions on the left of the — > 
are separated by commas, and assumptions used in the application of a rule are 
underlined) : 



{x<y/\y<z)=>xAz — 1 

x < y A y < z — > x A z — l 



x < y A y < z, x < z — 1 



(imp_intro) 
(lt_lt_trans) 
x A z — 1 (lt_imp_neq) 
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Its corresponding proof schema Schema{P . 1) is: 

(X fi Y A y /i Z) => X h (Z f 3 W) 

X h y AY /i Z — ► X h (Z f 3 W) 

X h Y A Y fi Z, X /i (Z f 3 W) — > X / 2 (Z f 3 W) 

For clarity the logical connectives A and =>■ have not been generalised to function 
variables - in practice we treat them the same as any other function symbols. 
Note that unlike the work of [4] , the schema is not a proof of a valid schematic 
theorem - it is simply used to guide the subsequent replay phase. 

In the replay phase, a schema is used to direct the proof of a target goal. This 
is achieved by replaying the source proof but with the single rule application at 
each step replaced by a search. The aim of the search is to produce a set of 
subgoals that match the corresponding subgoals of the schema; unifying each 
subgoal with its analog instantiates the schema. 

For example, suppose we want to use the schema in the previous example to 
prove the following: 



(x>yAy>z)=>x — l^z (£- 1 ) 

Because L.l is not an instance of the schema goal, the first step is to use a rule 
to transform i-l/ztoi/z + l. Instantiating the schema goal with the 
result gives the following: 

(x>yAy>z)=>x^z+l 

x > y A y > z — > x ^ z + 1 

x > y A y > z, x > z + 1 — > x ^ z + 1 

Note that although this is a total instantiation of the schema, the remainder of 
the replay must still be completed to justify the proof steps suggested by the 
instantiated schema. This is a trivial process for our simple example since each 
of the required steps corresponds to an existing inference rule. 

4 Goal-Directed Schema Generalisation 

In the previous section we assumed the target conjecture was simply unified with 
the schema root (possibly after an initial transformation). This will not always 
be possible, however. For example, suppose we try to use Schema(P.l) to help 
prove the goal: 



(x<yAy<z)^x^z (L.2) 

Here, fi cannot be instantiated to both < and <, and the term ( Z f 3 W) does not 
match the analogous term z in the target goal 1 . Using higher-order unification [3] 

1 Note that for this simple example, the analogical replay may, depending on the search 
depth, find that L. 2 could be transformed to x < y A y < (z + 1) => x (z + 1) — 1 
(which is an instance of the schema root). In general, such a transformation may 
not exist. 
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(the approach many accounts of proof reuse in the literature take) would allow 
the generalisation of the (Z f 3 W) term, however no term can be globally 
substituted for /) to produce a sufficiently general schema. 

In this section we describe an algorithm that uses both a more fine-grained 
version of unification together with anti-unification to generalise a schema based 
on the form of the target goal (hence the term goal-directed). To motivate the 
design of the algorithm, the exposition follows the calculation of the above gen- 
eralised schema. 



4.1 An Algorithm for Schema Generalisation 

The first step of our schema generalisation algorithm relies on anti-unification 
[8], an operation that calculates the least general generalisation (LGG) of a set 
of terms. Given two terms t\ and 1 2 we say that t\ is more general than 1 2 if we 
can find an substitution 9 such that t\9 = fa. We say that g is a generalisation 
of a set of terms E provided it is more general than each term in E, and define 
it to be the LGG of E provided every generalisation of E is more general than 
g. A set of terms has at most one LGG (up to variable renaming). 

The standard anti-unification operation fails for terms built from either dif- 
ferent function symbols, or for function symbols with different arities, however 
for our purposes we require this condition to be relaxed (since we will always 
want the anti-unification to succeed). Specifically, if the function symbols have 
different arities, the terms are generalised to a variable, while if the arities are 
the same but the function symbols are different, the generalisation consists of 
a term with the same arity but with a variable in place of the function symbol 
(the subterms are recursively anti- unified as normal). 

The procedure we use for schema generalisation is a variant of the original 
schema construction technique that starts not with a variable, but with the LGG 
of the target goal and the root of the original schema. For our example, consider 
the target goal L. 2 and the root of Schema(P. 1): 

(x<y/\y<z)=>x=£z and (X f x Y A Y f x Z) => X h (Z f 3 W) 

The LGG of these terms is (where we have used variable names from the root 
of Schema(P.l) wherever possible): 

(X ft Y AY U Z)=> X fa A 

By reconstructing the schema using the generalised target goal as a base, the 
idea is that the original schema will be generalised in exactly those locations that 
are required to accommodate the target goal, i.e., a kind of least generalisation 
of the schema. For this to happen, however, we must ensure that we only allow a 
(partial) one-sided unification when the generalised rule is applied - specifically, 
the generalised target goal should be frozen so the schema construction does 
not erase the results of performing the original anti-unification (freezing a term 
prevents variables occurring in that term from being instantiated). 
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As a consequence of beginning the schema construction with a (frozen) term 
that does not unify with the goal of the original schema, a schema construction 
step is now more complicated than just a simple unification of an open node 
in the schema with the goal of a generalised rule (otherwise at least one such 
step will fail). Specifically, at each step a structural mapping between terms is 
constructed and used to partially unify the terms, producing a more fine-grained 
unification that always succeeds. 

To see how this works, we show how the schema in our previous example can 
be calculated. We start with the frozen generalised target goal: 

(X fi Y A Y fi Z) =► X f 2 A 

The first step of the schema construction (applying the generalised form of 
imp-intro) can be carried out using normal unification. The schema afterwards 
is: 



(X fi Y A Y fi Z) X f 2 A 

(X fi Y A Y fi Z) — > X f 2 A 

Now consider the rule lt-lt-trans (left) and its generalised form (right) that we 
wish to apply: 

T, H < J - 1 — -> G r, H fi ( J fi K)—>G 

r — > g r — > g 

(provided H < I A I < J) (provided H fi I A I f "5 J ) 

The provided clause is a constraint on the applicability of lt-lt-trans; more 
precisely, the application of the rule will cause the {H < I A I < J) term to 
be unified with an element of the context F, e.g. with (x < y A y < z) in 
the original proof. Such a unification is not possible in the construction of the 
schema, however, since the (X fi Y A Y f. 4 Z) term is frozen. To proceed with 
the application of this rule in the construction of the generalised schema, we 
consider a structural subterm mapping between the open schema node and the 
generalised conclusion of lt-lt-trans (including the provided clause), which we 
represent as a set of unification problems PSet: 

PSet = {X~ H,fi~ fi,Y~ I,U ~h,Z~ J . ( ■ X fi A ) ~ G} 

Here, frozen variables have been underlined. Now we are faced with a problem 

- not all of these unification problems can be solved together. In particular, if 
fi ~ fi is solved by instantiating fi to fi, we cannot solve fi ~ fi, but if we solve 
fi ~ fi first we cannot solve fi ~ fi. Informally then, we want to perform those 
unifications that have no effect on the success of other unification problems. We 
call the set of such unifications the Unification-Independent Subset ( UIS ) 

- it is defined as follows. 

Definition 1. We say a set of unification problems R can be solved provided 
each of the constituent unification problems can be solved (the order in which 
the problems are attempted is irrelevant) . A set of unification problems R that 
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cannot be solved is said to be a minimal failure set iff for every problem r £ R, 
R\{r} can be solved. The UIS of a set of unification problems R (UIS(R)) is 
then the set of problems that don’t occur in any of the minimal failure sets of R. 

We can calculate the UIS with the algorithm of Fig. 2. The algorithm in the 
worst case has to analyse 2" sets (summing the first n rows of Pascal’s triangle). 
Importantly, in our domain, because n is small (< 10 for all the inference rules 
used in the Dutch National Flag case study), this ensures the algorithm executes 
(virtually) instantaneously. 



UIS(R) = 

n := 1, FS := {}, working := {{</} | q £ R} 
while #{s | s € working A = n} > 0 do 
for s £ {s | s £ working A Us = n} do 

if s cannot be solved and not 3 / : FS • / C s then 
FS := FSU{s} 
elseif s can be solved then 

working := working U (J{{r} U s \ r £ R\s} 
n := n + 1 
return R\ (J FS 



Fig. 2. An algorithm for calculating the Unification-Independent Subset of a set of 
unification problems R 



Returning to our example schema generalisation, solving all the unification 
problems in UlS(PSet) gives the following: 

(X /i Y A Y U Z) f 2 A 

(X fi Y A Y U Z) — + X f2 A 

(X fi Y A Y U Z),X h ( Z f e K) — ♦ X f 2 A 

To finish the schema construction, we want to apply the generalised form (right) 
of lt._imp-neq (left): 



L< M — ► L/ M L f s M — > L f 9 M 

The structural mapping for this step is: 

{X ~ L,ff ~ f 8 , (Z f 6 K) ~ M, A ~ M,/ 2 ~ f 9 } 

Performing all of the unifications except for (Z K) ~ M and A ~ M gives: 

(X fi Y A y U Z) => X ft A 

(X h y A y U Z) — ♦ x f 2 a 

x /i y A y U Z,x / 8 (z / 6 k ) — > x h a 
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While the resulting schema is more general than the original schema, it is not 
quite what we want - intuitively, every occurrence of (Z fg K) should be replaced 
by a variable. If we reexamine the structural mapping we can see why - the same 
range variable M is related to both the frozen term A (a term from the goal) 
and the compound term {Z fg K ) whose functor (fg) is not frozen (i.e. a term 
introduced by the proof). Hence we replace all occurrences of {Z fg K) in the 
schema with A. This gives the fully generalised schema: 

(X h Y A Y U Z)=>X f 2 A 
X /i Y A Y U Z — > X f 2 A 

X h Y A y U Z, x fs A — > X f 2 A 

This schema can be used to produce the following analogous proof: 

(x<yAy<z)=>x^z (impjntro) 

x < y A y < z — > x ^ z (lt_leq_trans) 

x < y A y < z, x < z — > x A z (lt_imp_neq) 

It must be noted that the development of the algorithm (and the generalised 
schemas it produces) was motivated and guided to an extent by experience with 
actual examples. It will always be possible to choose a combination of proof 
schema and target goal for which the algorithm arguably does not produce the 
ideal schema, possibly because the schema and target goal make no sense as a 
reuse combination. The results of Sect. 6 provide an indication of the usefulness 
of the algorithm in practice. In addition, by avoiding the use of higlrer-orcler 
unification, we avoid having to heuristically choose between the multitude of 
solutions to a particular unification problem - this becomes an efficiency issue 
for a flexible replay strategy such as the one we propose in the following section. 

5 A Replay Strategy 

In this section we describe an algorithm that addresses the following problem: 
given a single source proof, how can this proof be used to guide the proof of a 
target conjecture within a reasonable amount of time? 

Because the algorithm essentially replays the source proof (but with each step 
of the source proof replaced by a search), we need a mechanism for evaluating 
how closely potential continuations in the target proof match the corresponding 
point in the generalised schema. For this purpose we use the sum of two metrics 
- the straightforward structural similarity metric of Fig. 3 and the generalisation 
metric of Fig. 4. The development of these metrics was guided by heuristics and 
experience. 

The structural metric is a straightforward comparison of the structural sim- 
ilarity of two terms. If, at the outermost level the two terms are the same, i.e. 
quantified expressions, compound terms with the same arity or atoms/variables, 
the measure is one plus the sum of the recursively calculated measures of the 
components of the terms (where applicable). Otherwise, the measure is equal to 



zero. 
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struct_sim(M , N) = 

if (var(M) V atomic(M)) and ( var(N ) V atomic(N)) then 
return 1 

elseif M = ( M q x • Mb) and N = (N q y • Nb) then 
return 1 + struct_sim(Mb, Nb) 

elseif M = MA n ) and N = Nf(NAi, NA n ) then 

return 1 + X/"=i struct-sim{MAi, NAi) 

else 

return 0 



Fig. 3. Metric for measuring the structural similarity of two terms - (M q x • Mb) 
denotes the quantified term where Mb is quantified by M q over x 



The generalisation metric measures, for two terms t\ and fo, how much t\ 
has to be generalised (via anti-unification) to accommodate <2 (in practice t\ is a 
node in the schema and t 2 is a proof node) . For example, consider the terms t\ = 
A(B(C), D(E , E , E)) and t 2 = I(J(K,L),M(0,Q,Q)). The anti-unification 
AU tt of t\ and t 2 is W(U,X(V, Y, F)). Writing this term as A( U, D{ V, E, E)), 
where variable names from ti have been used where possible, highlights what 
we mean by “the amount t\ has to be generalised to accommodate t 2 ” - the 
new variables U and V have replaced the B(C ) term and the first occurrence of 
E respectively. We can measure the amount of generalisation by analysing the 
output of a structural mapping function applied to t\ and AUtt that has been 
modified to return a bag of mappings (that may contain repeated elements): 

[A* W, B(C) i—> U, D i—> X, E i—> V, E >—>■ Y,E >-> Yj 

Because AU tt is a generalisation of U , this bag can only contain two types of 
elements: mappings from non-variable terms to variables and mappings from 
variables to variables. For the non-variable mapping case, each (non-variable) 
domain element contributes its term weight to the measure. For the variable- 
variable case, we consider the set of subbags that have common domain elements. 
For our example this is: 

{[T^ WHD^XHE^ V,E^ Y,E ^ Yj} 

{l(A ^W)^ 1], l(D ^ X) ^ 1], {(E h F)h1,(£h 7)h 2]} 

Then each subbag contributes the number of elements in that bag minus the 
frequency of the element that occurs the most. In this case, the only subbag 
that contributes to the measure is l(E i— > V) i— > 1, (E i— > Y) i— > 2] which 
contributes 1. 

We combine the metrics as follows. 

Definition 2. For proof node p n of the form r p — > G p , and schema node q n of 
the form r q — > G q , we define the measure of p n and q n , measure(p n , q n ) as 
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gen-required (t \ , tz) 
total := 0 

Alfa '■= anti-unify(ti,h) 

ML := structural-mapping -bag (ti, AUtt) 
for e £ dom ML such that non-var(e. 1) do 
total := total + ML{ \e * term-weight (e.l) 
for e £ dom dom ML such that var(e) do 
subbag := {x : dom ML \ x.l = e} < ML 
total := total + if sub bag— max (ran subbag) 
return total 



structural-mapping _bag is similar to the structural mapping function used 
in the previous section but returns a bag of mappings. The expression ML$f 
gives the frequency of / in the bag ML. dom ML gives the set of elements 
in the bag ML (in this case a set of ordered pairs), dom dom ML gives the 
set of domain elements of that set. e.l refers to the domain element of the 
ordered pair e. Finally, term-weight(T) returns a number representing the 
size of the term T, and is equivalent to structsim(T , T). 



Fig. 4. Required generalisation metric 



the maximum of the expression structsim (( r pc , G p ), ( P q , G q )) — ( gen-required 
{{r pc ,G p ),(r q ,G q )), where r pc ranges over all the permutations of ffr q ele- 
ments of r p . 

In other words, measure chooses which context elements to measure against so 
as to maximise the result. To describe the main replay algorithm itself we need 
to consider one final definition. 

Definition 3. For two nodes p n and q n of the form r p — > G p and r q — > G q , 
we define the node unification operation p n q n to be G p ~ G q , solve(A), 
where A is a set consisting of one problem c p ~ c q for each element c p £ r p , 
where for each c q , c q £ r q , (solve(A) simply performs the unifications in A). 

Informally, apart from unifying the succeedants, node unification requires 
that each element of the context of p n be unified with an element of the context 
of q n - this is needed when proof nodes are unified with schema nodes. 

Now we can turn to the main replay algorithm itself which we describe in two 
parts - an initial portion which deals with the initial search and generalisation 
(replay), and a portion that replays each step of the original proof (replay step) . 
These are shown in Fig. 5. 

The algorithm is parameterised by the amount of initial search performed 
(IDEPTH), the amount of search performed to find an analogous continuation 
of each step of the source proof (SDEPTH), and the depth of the search used 
to automatically close any leftover proof nodes (ADEPTH). 
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replay (p n , S) = 

C = generate-Continuations(p„, IDEPTH) (INITIAL SEARCH) 

choose c£ C; On £ open-nodes(c) such that the value of 
measure(o n , root(S)) is maximised 
S g = construct-genschema(root(S) , o n ) 
solve(o„ ~ root(Sg)) 
for each r n £ open-nodes(c)\{o n } 

close(r n , ADEPTH) (INITIAL CLOSE) 

replaystep(o n , root(S g ), construct-subschemas (root(S))) 

replaystep(p n , s n , Subschemas) = 

C = generate-Continuations(p n , SDEPTH) (STEP SEARCH) 

choose c £ C; o s C open-nodes(c) such that cansolve(A) , 

where A is a set consisting of one problem o s ; s c ; for each 
Osi £ o s , where s c i £ children(s n ) 
for each ( o s i ~n s c i) £ A 

Osi Sci 

replay_step(o s i, s c i, Subschemas) 

OR 

choose S £ Subschemas such that the value of measure(p n , root(S)) 
is maximised 

S g := construct-genschema(root(S), p n ) 
replaystep(p n , root(S g ), {}) 

OR 

close(p n , ADEPTH) (AUTO CLOSE) 

generate-Continuations(p n , D) generates a set of (incomplete) proof fragments 
rooted at p n of depth D, where we use depth to mean the number of 
proof steps (either tactics or atomic inference rules) applied to construct 
a subproof, open-nodes(c) returns the open subgoals of the proof fragment 
c. close(o n , DEPTH) attempts to find a proof of the open node o n in at 
most DEPTH proof steps via an exhaustive search. cansolve(A) holds if 
the set of (node) unification problems A can be solved. For a schema S, 
construct-Subschemas(S) returns a set of schemas, one constructed at each 
node in S (note that this is not the same as simply taking subtrees of S). 
construct-genschema refers to the algorithm described in the previous section. 
The (choose c £ S such that E) construct chooses an element c of S that makes 
the expression E true. 



Fig. 5. The main replay algorithm - the four different ways in which steps in the target 
proof can be generated have been labelled 



replay takes two arguments - the goal p n to be proved, and a schema S 
that will be used in the analogous proof construction. Initially, replay chooses 
the continuation from the original target node that contains an open node that 
most closely matches the schema root - additionally it must be possible to close 
(i.e. prove) the remaining open nodes. To ensure the replay terminates in a 
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reasonable amount of time, the replay only attempts to proceed from the best 
initial continuation. The best initial open node is used as the target goal for the 
purposes of constructing the generalised proof schema, replay then hands over 
to replaystep which recursively follows the schema. At each step, it does one of 
the following: 

1. chooses a continuation such that for each open node there is a unifiable child 
node of the current schema, unifies and recursively replays each of them (note 
that this is how the analogous proof of Sect. 3 would be constructed), or 

2. provided the replay is currently operating on the original schema (to prevent 
recursive explosion), chooses a schema, closest matching first, constructed 
from a subproof of the original proof and replays the node with that schema 
but with no initial search, or 

3. closes the node via an automatic brute-force search 

For option 2, we make a trade-off we allow multiple subschemas to be 
tried however we do not permit any initial search - due to the need to measure 
many permutations of context for multiple open nodes in many continuations, 
initial search is a very expensive operation. Option 2 also prevents the recursive 
application of subschemas - once the replay begins operating on a subschema, it 
cannot further on in the replay start operating on yet another subschema. Also, 
for the purposes of this section we are assuming a single source proof as input, 
however in a situation in which, for example, the entire proof of correctness of 
the Dutch National Flag problem was being constructed, there would obviously 
be opportunities to use subschemas from outside of the chosen source proof. 
Finally, for option 3, to keep things simple we are just using a basic search 
- obviously this could be replaced with more domain-specific alternatives, e.g. 
tactics specialising in propositional logic. 

Using subschemas gives the replay strategy considerable flexibility by allow- 
ing a general rearrangement of subtrees in the original schema, including, for 
example, the deletion of parts of the original schema (achieved by choosing a 
subschema from further up the tree). Additionally, it allows a fresh instantiation 
of the schema at a given point to be made, something which we have found to 
be occasionally necessary. 

5.1 An Example Replay 

As an example of how this strategy works in practice, we consider the Blue. 1 
subproof of Fig. 6. This is a high-level view of the proof in that most of the steps 
shown actually correspond to the application of high-level tactics (and hence the 
application of multiple inference rules/step) - for the purposes of this exposition, 
this prevents the essence of the replay from being obscured. 

We have implemented our replay strategy in the Ergo theorem prover [9]. 
Fig. 7 shows the proof of Blue . 3 that was discovered fully automatically by our 
implementation (with IDEPTH = 1, ADEPTH = 2 and SDEPTH = 1) using 
the Blue. 1 subproof as source. Each node has been labelled with the part of 
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[1] ... — > V i • (0 ^ i A i < r) h(w, b — 1 : h.(b — 1), h.w).i = red 

[1.1] ...,V i • (0 ^ i A i < r) => h.i = red — ♦ 

Vi • (0 < i A i < r) => h.i = red 

[1.2] ..., i < r , r ^ w — > i ^ w 

[1.2.1] .... i < w — > i ^ w 

[1.3] ..., i < r , r ^ w — > i b — 1 

[1.3.1] ..., i < w,w ^ b,w^b, — > i ^ b — 1 

[1. 3.1.1] .... i < w , w < b — > i ^ b — 1 

[1.3. 1.1.1] ..., i <b - 1 — > i=£b- 1 



(not_eq) 

(assump) 

(lt_leq_trans) 

(lt_imp_neq) 

(lt_leq_trans) 

(lte_neq_imp_lt) 

(lt_lt_trans) 

(lt_imp_neq) 



Fig. 6. Proof of Blue.l 



the replay strategy that produced it along with the root schema node it was 
operating on at the time. 

Notice the initial step - splitting the V quantifier yields a proof node that 
more closely resembles the root of Schema(Blue.l) . Also of interest is the use of 
the subschema 1.3.1 to close the node 1.1.2 - this schema was the closest match 
that allowed node 1.1.2 to be closed. 

6 Case Study Results 

In this section we report on the results of applying the replay strategy described 
in the previous section to the Dutch National Flag case study. Fig. 8 shows the 
outcome of using each subproof of the invariant maintenance proof to prove each 
of the other subproofs. 

Each 3-tuple represents the minimum amount of search required to discover 
the analogous proof - the first number is the auto-close depth, the second is 
amount of step search, and the third is the amount of initial search. To give an 
idea of execution times, on a Pentium IV, schema construction/generalisation 
took approximately 2 seconds (for subproofs of around 50 proof nodes). For the 
replay itself, using a tactic/rule base of around 100 rules, the replay strategy 
took no longer than a minute to terminate. 

Even with these limits, the results of Fig. 8 suggest around 70% of user 
interactions can be saved for this part of the proof. Of course, user interactions 
is just one measure of proof complexity - another is the amount of time the 
user spends thinking about the proof. Experience has shown that for this kind 
of proof, the first subproof is usually the most time-consuming - indeed, in 
constructing the proof by hand, the first subproof took approximately twice as 
long as each of the others. Even given this, proof reuse still clearly provides 
significant savings. 

Finally, we would briefly comment on the problems the replay strategy has 
with finding an analogous proof for Red . 2 - this is due to inaccurate measures, 
especially at the initial search stage. In general, we have found that it is impor- 
tant to do as much initial search as possible so that the generalised schema that 
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h(w, b — 1 : h. (b — 1), h.w).i = blue 



Step Search(I) 

[1.1.1] ...,V i • (b ^ i A i < n) => h.i = blue — » 
Vi • (!) ^ i A i < n) =1 h.i = blue 




(split_l) 

(not_eq) 

(assump) 

(lt_leq_trans) 

( It e_neq_imp_lt ) 

( neq_flip ; lt_imp_neq) 
( leq_imp_minus 1 ) 

( neq_flip ; lt_imp_neq) 
(refLeq) 

(assump) 



Fig. 7. The proof of Blue. 3 



is constructed is as accurate as possible. For the case of Red. 2, either reattempt- 
ing the reuse using lower-rated initial continuations (i.e. modifying the replay 
strategy) or simply increasing the depth of the initial search allows the reuse to 
succeed. 

7 Conclusion 

In this paper we have described a method for reusing proofs. We contend that 
the combination of our goal-directed generalisation technique together with a 
flexible replay strategy can provide significant savings for the kinds of proofs that 
arise in the realm of software verification. Recently we have developed a reuse 
agent based on the reuse technique described in this paper as part of an agent- 
based distributed interactive theorem proving environment. Early indications of 
the agent’s effectiveness are promising - because the agent is running in the 
background, the search space of the replay can be increased. Further, the agent 
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Blue.l Blue. 2 Blue. 3 Red.l Red. 2 Red. 3 


Blue.l 
Blue. 2 
Blue. 3 
Rcd.l 
Red. 2 
Red. 3 


(0,1,0) (1,1,0) (2,1,1) (2,1,1) X (3,1,0) 

(3.1.0) (0,1,0) (2,1,1) (2,1,1) x (3,1,0) 

(2.1.0) (2,1,0) (0,1,0) (3,1,0) x (3,1,0) 

(3.1.0) (2,1,0) (3,1,1) (0,1,0) (2,1,2) (4,1,0) 

(4.1.0) (3,1,0) x (3,1,0) (0,1,0) (3,1,0) 

(2.1.0) (2,1,0) (2,1,1) (2,1,1) x (0,1,0) 



Fig. 8. Results of using each subproof to prove every other subproof - an ’x’ indicates 
the replay strategy failed to find an analogous proof given maximum search depths of 
(4,2,2) 



can also generically make use of the capabilities of other agents in situations 
where the replay encounters subgoals that it cannot solve itself. 
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Abstract. Distributed groupware systems consist of a group of users 
manipulating a shared object (like a text document, a filesystem, etc). 
Operational Transformation (OT) algorithms are applied for achieving 
convergence in these systems. However, the design of such algorithms is 
a difficult and error-prone activity, since building the correct operations 
for maintaining good convergence properties of the local copies requires 
examining a large number of situations. In this paper, we present the 
modelling and deductive verification of OT algorithms with algebraic 
specifications. We show that many OT algorithms in the literature do not 
satisfy convergence properties unlike what was stated by their authors. 



1 Introduction 

Distributed groupware systems consist of two or more users (sites) that simul- 
taneously manipulate objects (i.e. text, image, graphic, etc.) without the need 
for physical proximity and enables them to synchronously observe each other 
changes. The shared objects are replicated at the local memory of each par- 
ticipating user. Every operation is executed locally first and then broadcasted 
for execution at other sites. So, the operations are applied in different orders 
at different replicas (or copies) of the object. This potentially leads to diver- 
gent (or different) replicas - an undesirable situation for distributed groupware 
systems [16]. 

Operational Transformation is an approach which has been proposed to over- 
come the divergence problem, especially for building real-time groupware [4, 15]. 
This approach consists of an algorithm which transforms, i.e. to adjust parame- 
ters, the remote operation according to local concurrent ones in order to achieve 
convergence. It has been used in several group editors [4, 13, 15, 14, 18], and more 
recently it is employed in other distributed systems as the generic synchronizer 
S 5 [11]. The advantages of this approach are: (i) it is independent of the replica 
state and depends only on concurrent operations; (ii) it enables an unconstrained 
concurrency, i.e. no global order on operations; (iii) it ensures a good responsive- 
ness in real-time interaction context. However, if OT algorithms are not correct 
then the consistency of shared data is not ensured. Accordingly, it is critical to 
verify such algorithms to avoid the loss of data when broadcasting operations. 
According to [13], the OT algorithm needs to fulfill two convergence conditions 
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C i and C 2 which will be detailed in Section 2. Finding such an OT algorithm 
and proving that it satisfies Cj and C 2 is not an easy task. This proof is often 
difficult - even impossible - to produce by hand and unmanageably complicated. 

Our Solution. To overcome this problem, it is necessary to encourage OT al- 
gorithm developers to write a formal specification, i.e. a description about the 
replica behaviour, and then verify the correctness of the OT algorithm w.r.t. 
convergence conditions by using a theorem prover. However, effective use of a 
theorem prover typically requires expertise that is uncommon among software 
engineers. So, our work is aimed at designing and implementing techniques un- 
derlying the development of OT algorithms which meet the following require- 
ments: (i) Writing formal specifications must be effortless, (ii) High degree of 
automation in the proof process. The developers should use the theorem prover 
as a (push-button) probing tool to verify convergence conditions. 

Using Observational Semantics, we treat a replica object as a black box [6]. 
We specify interactions between a replica object and a user. Operations which 
observe the replica states are called attributes, and operations which change 
the states are called methods. We can only recognize the current state by ob- 
serving states modified by methods through attributes. So, we consider method 
sequences followed by an attribute as observation tools. We have implemented 
our approach as a tool which enables a developer to define all replica operations 
(methods and attributes) and the OT algorithm. From this description, our tool 
generates an algebraic specification described in terms of conditional equations. 
As verification back-end we use SPIKE, a first-order implicit induction prover, 
which is suitable for reasoning about conditional equations [2,3]. 

The main contribution of this paper is to show that a lightweight use of for- 
mal verification techniques is feasible (i) to write easily a formal specification of 
a replica object, and (ii) to have its OT algorithm checked w.r.t. convergence 
conditions so as to increase confidence in the correctness of the OT algorithm. 
Moreover, using our theorem-proving approach we have obtained surprising re- 
sults. Indeed, we have detected bugs in several distributed groupware systems 
designed by specialists from the domain [7, 8] . 

Related Work. To our best knowledge, there is no other work on formal veri- 
fication of OT algorithms. In [8], we represented the replica as an abstract data 
type, but the proof effort became costlier when the data is complex ( e.g . an 
XML tree). Indeed, a property proof involving the data could call for numerous 
sub-proofs of properties about its logical structure. In [10,9], we used the situ- 
ation calculus for hiding the internal state of replica but this formalism turned 
out to be inappropriate to accurately model the notion of state. In this work, we 
found that the observational semantics is natural enough to abstract away from 
the internal replica structure. It describes the behaviour of a replica object as 
viewed by an external user. Since OT algorithms rely on replica methods, then 
the process verification becomes effortless. 

Structure of the Paper. This paper is organized as follows: Section 2 summa- 
rizes the basic concepts of OT approach. The ingredients of our formalization for 
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specifying replica object and OT algorithm are given in Section 3. In Section 4, 
we present how to express convergence conditions in our algebraic framework. 
Section 5 briefly describes our tool and numerous bugs that we have found in 
some distributed groupware systems. Finally, we give conclusions and present 
future work. 

2 Operational Transformation Approach 

Distributed groupware systems typically maintain shared state of some sort ( i.e . 
text document, XML tree, etc.). Shared states are usually replicated among a 
group of sites. Updates are performed first at local sites and then propagated 
to remote sites. When the replicated state is being modified, all the replicas 
must be modified in a consistent way. In the following, we consider a distributed 
groupware system as a Group of Sites ( GS ) where every site has its own replica. 
Notation [op\ op2 ■ ■ ■ op n \ represents an operation sequence. We denote X • st = 
st' when an operation (or an operation sequence) X is executed on a replica 
state st and produces a replica state st'. 

Definition 1. (Convergence Property). The convergence property states 
that all replicas are identical at all sites after all generated operations have been 
executed at all sites. 

Example 1. Consider the following group text editor scenario (see Figure 1): 
there are two sites working on a shared document represented by a string of 
characters. Initially, all the copies hold the string “efect”. The document is 
modified with the operation /ns(p, c) for inserting a character c at position 
p. Users 1 and 2 generate two concurrent operations: opi = Ins( 2, “f”) and 
op 2 = Ins( 6, “s”) respectively. When opi is received and executed on site 2, 
it produces the expected string “effects”. But, when op2 is received on site 
1, it does not take into account the fact that opi has been executed before it. 
Consequently, we obtain a divergence problem between sites 1 and 2. 

As a solution to divergence problem, we can use an OT algorithm which has 
been proposed in [4]. It takes two concurrent operations opi and op2 defined 
on the same state and returns op\ which is equivalent to op± but is defined on a 
state where op2 has been applied. We denote this algorithm by a function T. 

Example 2 . In Figure 2, we illustrate the effect of T on the previous exam- 
ple. When op 2 is received on site 1, op2 needs to be transformed according to 
opi as follows: T((/ns(6, “s”), /ns(2, “f”)) = Jns( 7, “s”). The insertion posi- 
tion of op2 is incremented because opi has inserted a character at position 2, 
which is before the character inserted by op2- Next, op 2 is executed on site 1. 
In the same way, when opi is received on site 2, it is transformed as follows: 
T(Ins (2 , “f”),/ns(6, “s”)) = Ins{ 2, “f”); op\ remains the same because “f” is 
inserted before “s”. 
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Fig. 1. Incorrect integration. Fig. 2. Integration with transformation. 



Intuitively we can write the transformation T as follows: 



T(Ins (pi , cl) , Ins (p2 , c2) ) = if (pi < p2) return Ins(pl,cl) 

else return Ins(pl+l,cl) 
endif ; 



However, using an OT algorithm requires to satisfy two conditions [13]. Given 
two operations opi and op 2 , let op' 2 = T(op 2 ,opi) and op[ = T(opi,op 2 ), the 
conditions are as follows: 



— Condition Ci: [op\ op' 2 \ • st = [op 2 op\ ] • st, for every state st. 

- Condition C 2 : T(T(op, opi), op 2 ) = T(T(op, op 2 ), op[). 

C i defines a state identity and ensures that if opi and op 2 are concurrent, 
the effect of executing opi before op 2 is the same as executing op 2 before opi. 
This condition is necessary but not sufficient when the number of concurrent 
operations is greater than two. As for C 2 , it ensures that transforming op along 
equivalent and different operation sequences will give the same result. In [14], 
the authors have proved that conditions C\ and C 2 are sufficient to ensure the 
convergence property for any number of concurrent operations which can be 
executed in arbitrary order. 

Proving the correctness of OT algorithms, w.r.t C\ and C 2 is very complex 
and error prone even on a simple string object. Consequently, to be able to 
develop the transformational approach and to safely use it in other replication- 
based distributed systems with simple or more complex objects, proving condi- 
tions on OT algorithms must be assisted by an automatic theorem prover. 
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3 Formal Specification 

We present in this section the theoretical background of our framework. We first 
briefly review the basics of algebraic specification. Then, we give the ingredients 
of our formalization for specifying and reasoning on OT algorithms. 

3.1 Algebraic Preliminaries 

We assume that the reader is familiar with the basic concepts of algebraic spec- 
ifications [19], term rewriting and equational reasoning [17]. Let 5 be a set 
(of sorts). An S-sorted set is a family of sets X = {X s } s6 s indexed by S. A 
many-sorted signature A is a triplet (S,F,X) where S' is a set (of sorts), F is 
a S* x S-sorted set (of function symbols) and A is a family of S-sorted vari- 
ables. tj (w, s) denotes the number of occurrences of the sort s in the sequence 
u>. We assume that we have a partition of F in two subsets: the first one C 
contains the constructor symbols and the second one D is the set of defined sym- 
bols, such that C and D are disjoint. Let T(F,X) be the set of sorted terms. 
When a term does not contain variables, it is called ground term. The set of 
all ground terms is T(F). A substitution g assigns terms of appropriate sorts 
to variables. If t is a term, then tO denotes the application of substitution 6 to 
t. If t) applies every variable to ground term, then g is a ground substitution. 
We denote by = the syntactic equivalence between objects. An equation is a 
formula of the form l = r. A conditional equation is a formula of the following 
form: A”=i a * = =>• / = r. It will be written /\"=i a * = l ~ r and 

called a conditional rewrite rule when using an order on terms. The precondition 
of rule ALi a i = fr* =>■ / — > r is A"=i ai = ^i- The term l is the left-hand 
side of the rule. A set of conditional rewrite rules is called a rewrite system. A 
constructor is free if it is not the root of a left-hand side of a rule. A term is 
strongly irreducible if none of its non- variable subterms matches a left-hand side 
of a rule in a rewrite system. An algebraic specification is a pair (A, A) where 
A is a many-sorted signature and A is a rewrite system (called the axioms of 
(X, A)). A clause is an expression of the form: A"=i a * = => Vjli a 'j = b'j- 

The clause C is a Horn clause if m ^ 1. The clause C is a logical consequence 
of A if C is valid in any model of A, denoted by A |= C. C is said induc- 
tively valid in A (denoted A\= Ind C), if for any ground substitution a, (for all 
i, £\= aicr = bi<j) implies (there exists j , A\= alcr = b)a). An Observational 
signature is a many-sorted signature S = (S, S 0 b s , F, X) where S 0 bs Q S is the 
set of observable sorts. An Observational specification is a pair (A, A) where E 
is an observational signature and A is a set of axioms. 

3.2 Replica Specification 

The main component in distributed groupware system is the replica. Every 
replica has a set of operations. The methods are operations which modify the 
replica state. The attributes are operations which extract informations from this 
state. In some cases, the replica state can be small, like a text document. In other 
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cases, it can be large like a database, an XML tree or a filesystem. In this work, 
we use an observational technique which conceals the internal state of the replica 
by extracting informations from the method sequence executed on it. 

We use the sort State for representing the space of replica state. This sort 
has two constructor functions: (i) the constant constructor So (the initial state), 
and (ii) a constructor Do which given a method and a state gives the resulting 
state provided that the execution of this method is possible. The sort Meth 
represents the set of methods. Every method type has its own constructor. These 
constructors are free since methods are assumed to be distinct. For every method, 
we should indicate conditions under which it is enabled. For this we use a boolean 
function Poss defined by a set of conditional equations. We define also an idle 
method which has null effect on the replica state, i.e. constructor Nop. As to 
attributes, we define them as function symbols which are monadic on the State 
sort. These attribute functions serve as observers and are inductively expressed 
upon the State sort. The OT algorithm is defined by the function symbol T 
which takes two methods as arguments and produces another method. We then 
formally define a replica specification: 

Definition 2. (Replica Specification). Given S the set of all sorts, Sbs = 
{State, Meth } the set of basic sorts and Si s = S\Sb s the set of individual sorts 
(data sorts). A replica specification 7r is an observational specification OSP 71 = 
(S n ,A n ) such that: 

— is an observational signature where the set of non- observable sorts is 
a singleton, i.e. S \ S a b s — {State}. F is defined as C U D, such that: 
(i) C}, state {So}, f- Meth state, state {-^o} and C u , s 0 if s is State or 
CO Contains an element of Sbs. (H) D\\q th Meth, Meth — {T} , -Dm eth State, Bool — 
{Poss} and D u , s = 0 if either s is State, u> contains Meth, or 
t ]{ lu , State) > 1. 

— A 7r = Vp U T>a U T>t is the set of axioms (written as conditional equations) 
such that: (i) Vp is the set of method precondition axioms (Poss); (ii) Va 
is the set of axioms for every attribute; (Hi) Vp contains axioms defining 
the transformation function T. 

Example 3. Consider the group text editor designed by Ellis and Gibbs [4] 
who are the pioneers of the OT approach. The string replica has two meth- 
ods: Ins(p,c,pr) and Del(p,pr) [4]. In this example, Ins and Del are extended 
with a new parameter pr. This one represents the priority to solve conflict when 
transforming two Ins operations and it is based on the site identifier where 
operations have been generated. The replica string has two attributes: Length 
for extracting the length of the string and Car for giving the character of the 
string at given position and state. The replica specification is given in Figure 3. 
The set Cf^eth (u> € S* s ) contains all constructor methods which represents the 
method types of a replica. All the necessary conditions for executing a method 
are given by Vp (lines 1 — 2). The set D u state, s contains all replica attributes 
where u € S* s and s € S ls . Va is illustrated in lines 3 — 9. Lines 10 — 25 gives 
the definition of T. true and false are boolean constants. 
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Sorts: State, Meth, bool, nat, char 

Constructors 

SO : — > State 

Do : Meth X State — > State 

Ins : nat X char X nat — > Meth 

Del : nat X nat — > Meth 

Nop : — > Meth 

Defined Operations 

Poss : Meth X State — > bool 

Length : State — > nat 

Car : nat X State — ► char 

T : Meth X Meth — > Meth 

Variables 

x, pi, p2, prl, pr2 : nat; 

st : State; 

m : Meth; 

cl, c2 : char; 

Axioms 

1. Poss(Ins(pl,cl,prl), st) = (pi < Length.(st)); 

2. Poss(Del(pl,prl), st) = (pi < Length(st)); 

3. Lengt.h(Do(Ins(pl, cl, prl), st)) = Length(st) + 1; 

4. Length(Do(Del(pl,prl), st)) = Length(st) — 1; 

5. x = pi =*• Car(x, Do(Ins(pl, cl, prl), st)) = cl; 

6. (x > pi) = true =*• Car(x, Do(Ins(pl,cl,prl), st)) = Car(x — 1, st); 

7. (x < pi) = true => Car(x,Do(Ins(pl,cl,prl),st)) = Car(x,st)\ 

8. (x > pi) = true => Car(x, Do(Del(pl), st)) = Car(x + 1, st); 

9. (x < pi)) = true =*• Car( x, Do(Del(pl), st)) = Car(x, st); 

10. T(Nop,m) = Nop; 

11. T(m,Nop)=m; 

12. (pi < p2) = true =» T(Ins(pl,cl,prl), Ins(p2,c2,pr2)) = Ins(pl,cl,prl); 

13. (pi > p2) = true => T(Ins(pl, cl, prl), Ins(p2, c2,pr2)) = Ins(pl + 1, cl, prl) 

14. pi = p2 A cl = c2 => T(Ins(pl, cl, prl), Ins(p2, c2,pr2)) = Nop; 

15. pi = p2 A cl ^ c2 A (prl > pr 2) = true =» 

16. T(Ins(pl, cl, prl), Ins(p2, c2,pr2)) = Ins(pl + 1, cl, prl); 

17. pi = p2 A cl ^ c2 A (prl < pr2) = true => 

18. T(Ins(pl,cl,prl),Ins(p2,c2,pr2)) = Ins(pl,cl,prl); 

19. (pi < p2) = true => T(Ins(pl, cl, prl), Del(p2,pr2)) = Ins(pl, cl, prl); 

20. (pi > p2) = true => T(Ins(pl , cl, prl), Ins(p2, c2,pr2)) = Ins(pl — 1, cl, prl); 

21. (pi < p2) = true =» T(Del(pl,prl), Del(p2,pr2)) = Del(pl,prl); 

22. (pi > p2) = true => T (Del (pi, prl) , Del(p2, pr2)) = Del(pl — l,prl); 

23. pi = p2 => T(Del(pl,prl), Del(p2,pr2)) = Nop; 

24. (pi < p2) = true => T (Del (pi, prl), Ins(p2, c2,pr2)) = Dei(pl,prl); 

25. (pi > p2) = true => T (Del (pi, prl) , Ins(p2, c2,pr2)) = Del(pl + l,prl); 



Fig. 3. Replica specification for text editor. 
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We use an observational semantics which is based on weakening the satisfac- 
tion relation [3, 1, 6, 5]. Informally speaking, the replica objects which cannot be 
distinguished by experiments are considered as observationally equal. When us- 
ing algebraic specifications, such experiments can be formally defined by contexts 
of observable sorts and operators over the signature of the specification. 

Definition 3. (Context). Let tt be a replica specification and T n (F, X ) its term 
algebra. 

1. A HV -context of sort State is a non-ground term c £ T n (F,X) with a 
distinguished linear variable zstate of sort. State. This variable is called the 
context variable of c. To indicate the context variable occurring in c, we 
often write c[z st ate]- 

2. A Sir -context c is called an observable E n -context if the sort of c is in Si s , 
and a State E„ -context if the sort of c is State. 

3. A State E n -context can be regarded as a sequence of methods. An observable 
E K -context is the sequence formed by an attribute and a State E K -context. 

4- A E^-context c is appropriate for a term t £ T n (F,X) iff the sort of t 
matches that o/ estate- c[t] defines the replacement o/zstate by t in c[zstate]- 
5. ObsCts „ denotes the set of all observable E n -contexts. 

Example 4- Consider the replica specification in Figure 3. There are infinitely 
many observable HV-contexts: Length(zstate), Car(x, Zstate), Car(x, Do(Ins(p, 
c,pr),z sta te )), • ••, Length(D o n (Del{p), zstate) ■ 

Our notion of observational validity is based on the idea that two replica 
objects in given algebra are observationally equal if they cannot be distinguished 
by computation with observable results. 

Definition 4. (Observational Validity). Two terms t\ and t 2 are obser- 
vational equal if for all c £ ObsCts n AT |= c[ti] = c[0]- We denote it by 
A* |=ob s fi = t 2 or simply ti = obs t 2 . 

The observational validity induces a congruence on T(F) [3]. 

Definition 5. (State Property). Let P = /\" = i a t = bi ==> t\ = t 2 . We say 
that P is a state property (or observational valid) and we denote it by A w |= 0 bs P 
if: for all ground substitutions a , (Vi £ [l..n] ajcx = 0 bs btcr) implies tier = 0 bs t 2 a. 

Our purpose is to propose a technique allowing to prove and disprove (or 
refute) state properties. Note that our state properties are Horn clauses and 
therefore in the scope of observational properties mentionned in [3]. In this work, 
the authors introduced the concept of critical contexts. They allow to prove ob- 
servational theorems by reasoning on the ground irreducible observable contexts 
rather than on the whole set of observable contexts. In the following, we denote 
by TZ a conditional rewrite system which is obtained by orienting axioms of AA . 

Definition 6. (Inconsistent State Property). We say that the state property 
P = A”=i a * = =>• ti = t 2 is provably inconsistent iff there exists a 

substitution a and a critical context c such that: (i) Vi £ [l..n], aicr = bia is an 
inductive theorem w.r.t. 1Z. (ii) c[#i = t 2 \ is strongly irreducible by 1Z. 
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Provably inconsistent state properties are not observationally valid. 

The computation of critical contexts requires that axioms are sufficiently 
complete [19]. Moreover, the refutation of any theorem imposes that 1Z is ground 
convergent. For more details on how to compute critical context and refute 
observational theorems can be found in [3]. We denote the inference system 
of [3] Proof(F/), which takes as argument a set of conjectures to be proved and 
returns a set of lemmas remaining to be proved in order to show E is obser- 
vationally valid. If Proof(£ i ) returns an empty set then E is observationally 
valid. 

4 Proving Convergence Properties 

Before stating the properties that a replica object has to satisfy for ensuring 
convergence, we give some notations. Let m i, m 2 , ■ ■ ■ , m n and st be terms of 
sorts Meth and State respectively. We define (the empty sequence is denoted 

by 0) : 

1. [](st) = st and [mi m 2 . . . m n \(st) = Do(m n , . . . , Do(m, 2 , Do{in\, st)) . . .) 
is the application of the method sequence mi, m 2 , . . . , m n on the state st. 

2. Legal([[, st) = true and Legal ([mi m 2 . . . m n ], st) = Poss(m\, st) A 
Poss(m 2 , [mi](st)) A . . . A Poss(m n , [mi m 2 . . . m n -i\(st)) . 

3. T*(m, []) = m and T*(m, [mi m 2 • • • m n ]) = T*(T(m, mi), [m 2 . . . m„]). 
T*(m, seq) denotes the operation resulting from transforming m along the 
sequence seq. 

Definition 7. (Sequence Equivalence). Given two method sequences seqi 
and seq 2 - We say that seqi and seq 2 are equivalent iff seqi(st) = 0 bs seq 2 (st) for 
every state st. 

In the following, we present how to express the satisfaction of conditions Ci 
and C 2 as properties to be checked in our algebraic framework. Let OSP * = 
(£ 7r ,A n ) and MA be a replica specification and the method set respectively, 
corresponding to a replica object it. 

4.1 Condition C\ 

As mentionned before, we use an observational approach for comparing two 
replica states. Accordingly, we define the condition Ci by the following state 
property (the variable st is universally quantified): 

<L>i(mi,m 2 ) = (Legal([miT(m 2 ,mi)\, st) = true A 

Legal([m 2 T(mi,m. 2 )\,st) = true) (1) 

==> [miT(m 2 ,mi)](sf) = obs [m 2 T(mi, m 2 )](sf) 

The first convergence property is formulated as a conjecture to be proved from 
the replica specification. It means: for all methods mi and m 2 and for every state 
st, such that mi and m 2 are enabled on st, then the states [mi T(m, 2 , mi)](sf) 
and [m 2 T(mi, m 2 )](sf) are observationally equal. This conjecture is defined as 
follows: 
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Input : A replica specification n. 

Output : S a set of CPl-scenarios. 

5 <— 0; 

foreach method Mi in A4 n 
foreach method M 2 in A4 n 
E 4- 

E «- Proof(F); 

if E ± 0 then S 4 - 5 U {(Mi, M 2 , F)} ; 

endfor 

endfor 



Fig. 4. Checking Algorithm of Convergence Property CP 1. 



Conjecture 1 (Convergence Property CPI). A replica object n satisfies the 
condition C\ iff <Pi(mi, m 2 ) is a state property for all m 1 and m 2 - 

According to Definition 7, the convergence property CPI means that the 
sequences [miT(m 2 ,mi)] and [m 2 T(mi, m 2 )] are equivalent. 

Definition 8. (CPl-scenario). A CPl-scenario is a triple (M-[ -M-i-E ) where 
M\ and M 2 are two methods and £ is the set of conjectures obtained by the 
function Proof({<? 1 (A/i, M 2 }). 

In Figure 4, we present an algorithm allowing us to verify the convergence 
property CPI by detecting all CPl-scenarios which violate this property. The 
CPl-scenarios simply consist of methods and conditions over argument methods 
which may lead to potential divergence situations. 

Example 5. Consider the group editor of Example 3. When applying our algo- 
rithm to replica specification of Figure 3, we have detected that convergence 
property CPI is violated by giving the CPl-scenario depicted in Figure 5. 
From this scenario, we can extract the following informations: (i) the methods 
(Ins(ul,u2,u3) and Del(vA,ufff) that cause divergence problem; (ii) the obser- 
vation (the attribute Car) that distinguishes the resulting states, and; (iii) the 
conditions over method arguments (Preconditions) which lead to divergence sit- 
uation. The counter-example is simple (as illustrated in Figure 6; for clarity we 
have omitted priority parameter): (i) user\ inserts x in position 2 (opi) while 
user 2 concurrently deletes the character at the same position (op-i). (ii) When 
op 2 is received by site 1, 0 P 2 must be transformed according to op\. So T(Del( 2), 
Ins(2,x)) is called and Del( 3) is returned, (iii) In the same way, op\ is received 
on site 2 and must be transformed according to op 2 - T(Ins(2, x),Del( 2)) is called 
and returns Ins(3,x). Condition C\ is violated. Accordingly, the final results on 
both sites are different. 

The error comes from the definition of T{Ins{p 1, cl,prl), Del(p2,pr2)). The 
condition p\ < P 2 should be rewritten p\ < p 2 - Other bugs have been detected 
in other string-based group editors [13, 15]. More details may be found in [8]. 
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Scenario 1 : 



opl : Ins (ul ,u2,u3) 
op2 : Del(u4,u5) 

51 [opl ; T(op2 , opl)] : 

[Ins(ul ,u2 ,u3) ;Del(ul+l ,u5)] 

52 [op2 ; T(opl , op2)] : 

[Del(ul , u5) ; Ins (ul-1 ,u2,u3)] 

Instance: Car(ul,Sl) = Car(ul,S2) 

Preconditions : 

(ul <= Length (u5) )=true /\ 

(u4 < Length(u5))=true /\ 
ul = u4; 



Site 1 : user t Site 2 ; user 2 




Fig. 5. Output of our algorithm. 



Fig. 6. Scenario violating CPI. 



4.2 Condition C 2 

C 2 stipulates a method identity between two equivalent sequences. Given three 
methods mi, m2 and m3, transforming m3 with respect to two sequences 
[mi T(ra2,mi)] and [m 2 T(mi,m 2 )] must give the same method. We define C2 
by the following property: 

^2 (mi, m 2 , m 3 ) = T*(m 3 , [mi T(m 2 , mi)]) = P*(m 3 , [m 2 T(mi, m 2 )]) 

The second convergence property is formulated as a conjecture to prove from 
the replica specification. 

Conjecture 2 (Convergence Property CP 2). A replica object n satisfies the 
condition C 2 iff: A |= 0 bs ^i(mi, m 2 , m3) for all methods mi, m 2 and m3. 

Definition 9. (CP2-scenarios). A CP 2— scenario is represented by a quadru- 
ple (Mi, M2, M3, £) where Mi, M2 and M3 are tree methods and £ is the set of 
conjectures obtained by the function Proof(<£ 2 (Mi, M 2 , M3)). 

A CP2-scenario simply gives methods and conditions that may lead to po- 
tential divergence situations. In Figure 7, we present an algorithm for checking 
the convergence property CP2. 

Example 6. Consider the replica specification of Figure 3 with the modification 
regarding T for satisfying the convergence property CPI (see Example 5). Using 
our algorithm, we have detected that convergence property CP 2 is not satisfied. 
In Figure 8 we give one of the CP 2-scenarios output by our algorithm. When 
analyzing this scenario, we notice that transforming opl along sequences 51 and 
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Input : A replica specification 7 r. 

Output : S a set of CP2-scenarios. 

5 <— 0; 

foreach method Mi in 

foreach method M 2 in JvP 
foreach method M 3 in M w 
E <- {<£ 2 (Mi,M 2 ,M 3 )}; 

E <— Proof(_B); 

if E ^ 0 then S <- S U {(Mi, M 2 , M 3 , E)}-, 

endfor 

endfor 

endfor 



Fig. 7. Checking Algorithm of Convergence Property CP'2. 



S 2 produces different methods (i.e. Ins(ul+1, m2, m3) 7 ^ Ins(ul, m2, m3). There is 
a divergence problem caused by the triple (Ins, Del, Ins). Consider for instance 
in Figure 9, three sites 1, 2, 3 start from the same initial state “abc”. They 
generate operations opi = Ins(3,y,l), op 2 = Del( 2,2) and op 3 = Ins(2,x, 3) 
concurrently, which change their states to “abyc”, “ac” and “axbc” respectively. 
At site 1, when op 2 is received, it is transformed against opi resulting in op 2 = 
Del( 2,2). After executing op' 2 the state becomes “aye”. When op 3 arrives, it is 
transformed against [opi op 2 ] resulting in op"\ — Ins(2,x,3) whose execution 
leads to state “axyc”. 

At site 2, opi arrives first and is transformed against op 2 resulting in op\ = 
Ins( 2, y, 1). After op\ is executed, the state becomes “aye”. And when op 3 arrives 
it is transformed first against op 2 resulting in op ' 3 = Ins( 2,x,3). Then op'\ is 
transformed against op[. Since the priority of op' 3 is greater than that of op[, it 
is shifted and we obtain op” 3 = Ins( 3, x, 3). After executing op” 3 = Ins( 3, x, 3), 
the state of site 2 becomes “ayxc” which is not identical to the state (“axyc”) 
of site 1. Consequently, this OT algorithm does not verify convergence property 
CP2. 

5 Implementation 

We have updated our tool VOTE (Validation of Operational Transformation Envi- 
ronment) [9] by implementing our observational approach-based technique. This 
tool is designed to automatically check convergence properties CP 1 and CP 2. It 
builds an algebraic specification described in terms of conditional equations. As 
a verification back-end (implementation of Proof function) we use SPIKE [3], 
an automated induction-based theorem prover. When SPIKE is called, either 
the convergence properties proof succeed and OT algorithm is validated, or the 
SPIKE’s proof-trace is used for extracting all scenarios which may lead to po- 
tential divergence situations. There are two possible scenarios: the first one is 
unnecessary because contains valid conjectures (resulting from correct scenario) 
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Scenario 1 : 



opl : Ins (ul ,u2,u3) 
op2 : Del(u4,u5) 
op3 : Ins(u6,u7,u8) 

51 [op2;T(op3,op2)] : 

[Del(u4,u5) ; Ins(u6-1 ,u7,u8)] 

52 [op3;T(op2,op3)] : 

[Ins(u6,u7,u8) ;Del(u4,u5)] 

Transforming opl/Sl: Ins (ul+1 ,u2,u3) 

Transforming opl/S2: Ins (ul ,u2,u3) 

Preconditions : 

ul = u4 /\ (u4 < u6)=true /\ 
ul = u6-l; 




Fig. 8. Output of our algorithm. 



Fig. 9. Scenario violating CP 2. 



Table 1. Case studies. 



Distributed Systems 


Ci 


c 2 


GROVE 


violated 


violated 


Joint Emacs 


violated 


violated 


REDUCE 


correct 


violated 


SAMS 


correct 


violated 


S5 


correct 


violated 



that SPIKE cannot reduce 1 . Such cases can be overcame by only introducing lem- 
mas. The second one concerns cases violating convergence properties. VOTE gives 
all necessary informations (methods and conditions) to understand the diver- 
gence origin. Consequently, these informations help developer to correct its OT 
algorithm. 

We have detected a lot of bugs in well-known group editors such that 
GROVE [4], Joint Emacs [13], REDUCE 2 [15] and SAMS 3 [12] which are based 
on transformational approach for maintaining consistency of shared data. The 
results of our experiments are reported in Table 1. GROVE, Joint Emacs and 
REDUCE are group text editors whereas SAMS is XML document-based group 
editor. S 5 4 is a file synchronizer which uses an OT algorithm for synchronizing 
many file system replicas [11]. 

1 like Car((p + 1) — 1, st) = Car((p — 1) + 1, st). 

2 http : //www. cit .gu . edu. au/^scz/project s/reduce 

3 http://woinville.loria.fr/sams 

4 http://woinville.loria.fr/ls 
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6 Conclusion 

We have presented our formal approach which is intended to automatically de- 
tect copies divergence in distributed groupware systems. To meet convergence 
requirement, the OT algorithm of these systems must be checked w.r.t. the con- 
vergence conditions C\ and Cn . This task is difficult - even impossible - to carry 
out by hand due to the numerous cases to test. To overcome this problem, we 
have proposed an algebraic framework to assist the development of correct OT 
algorithms. Thanks to our framework, we have detected bugs in many well-known 
systems. So, we think that our approach is very valuable because: (i) it can help 
significantly to increase confidence in an OT algorithm; (ii) having the theo- 
rem prover ensures that all cases are considered and quickly produces counter- 
example scenarios; (iii) formalization is very easy and effortless. A drawback of 
this framework is that the user have to identify which set of characteristics gives 
a complete observation of the replica object. However, this can also be viewed 
as an advantage because the complexity of the proof is highly reduced. 

Future Work. Many features are planned to deal effective and large systems. 
We plan to ensure the correct composition of many OT algorithms for handling 
composed objects. Finally, we intend to integrate in our framework the genera- 
tion of Java classes from correct OT algorithms. 
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Abstract. This paper presents a major Java source code verification 
case study that was carried out within the European VerifiCard project. 

It involves a realistic smart card applet from the company Schlumber- 
gerSema that has been verified with several tools in parallel, in order 
to assess the state of the art in formal verification. The paper describes 
part of the verification - using the static checker ESC/Java2 and the 
verifiers Jive, Loop and Krakatoa- and reports on the experiences and 
outlook. 

1 Introduction 

The European project VerifiCard has been running for almost three years from 
2001 to 2004. Its aim was to apply formal techniques in the area of Java-based 
smart cards, both at the byte code and source code level, in order to provide the 
smart card industry with tools and techniques for higher levels of certification - 
typically within the Common Criteria framework. The VerifiCard project did not 
focus on the use of one particular tool, but involved the parallel use of several 
tools in order to stimulate coordination and comparison. At the start of the 
project it was felt that the area was too young and immature to restrict to one 
particular technique or tool. This approach is reflected in the current paper. 

Within this framework the VerifiCard participant SclrlumbergerSema 1 has 
provided the project with source code of one of its applets, together with a 
set of security properties that it wants certainty about. It is a commercially 
developed applet that has been sold to customers, and therefore, several aspects 
of it (and of the required security properties) have to remain confidential. We 
thus refer to the applet simply as the “SLB applet”. 

For the specification of Java source code properties the language JML [2] is 
developing into a (de facto) standard - in part as a result of the activities within 
the VerifiCard project. This paper describes our experiences in applying tools 
for JML-based source code verification, namely Jive [14], Loop [9] and Kraka- 
toa [13], as well as the static checking tool ESC/ Java [12] (and its successor 

* Funded by EU 1ST project IST-2000-26328- VERIFICARD, www.verificard.org 
1 Since jan. 1 2004 SchlumbergerSema’s smart card group has become part of Axalto. 

Here we shall use the old name SchlumbergerSema that was used within the project. 
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ESC/JAVA2 [3]). The paper presents a short overview of the methodologies that 
the different verification tools are based upon, demonstrates how the tools have 
been applied to the case study, and what their respective achievements in the 
verification of the applet are - namely the detection of some bugs. 

The paper is organised as follows. The SLB applet and its specification are 
introduced in Section 2. The subsequent five sections present the various tools 
that have been applied to the applet and the results achieved with them. Finally, 
Section 8 draws some conclusions. 

2 Outline of the SLB Applet 

This section presents some background information about the applet under in- 
vestigation. The confidential nature of the applet imposes some restrictions on 
what can be said. However, these restrictions do not really affect the explanations 
of the scientific aspects of the investigation. 

The applet has been provided by SclrlumbergerSema “as is” , that is without 
any additional documentation. The code itself does contain some rudimentary 
comments, but they are mostly concerned with specific details, and not with the 
big picture. We had to reconstruct that ourselves. This first step of the work, done 
by Hans Meijer and Bart Jacobs at Nijmegen, was to write a JML specification 
for the SLB applet. The specification was based purely on code inspection. The 
unclarities that emerged were discussed with SclrlumbergerSema. At this stage 
the specification was only typeclrecked, and not verified. It was then distributed 
to the four verification teams, who adapted it to their own needs. 

2.1 Structure of the Code 

The main part of the SLB applet is a 2-dimensional array of bytes, representing 
a rudimentary file system. One immediate problem is that Java Card does not 
allow multi-dimensional arrays. The trick used in the applet is to define an array: 

Object [] o_Records ; 

Within the applet, each object in o_Records will then store a byte array, called 
a record. This intention can be made explicit in a JML class invariant, as: 

o_Records [ i ] instanceof byte[] &fc 
2 (( byte []) o.Records [ i ]). length = record_length && ... 

where i lies in an appropriate range. As stated, these records all have the same 
length, described here as a JML model field recorcLlength. The first entry 
o_Records [i] [0] , if non-zero, is used to indicate the length of the data in the 
record o_Records [i] . 

All this makes the class invariant an essential part of the specification: it 
expresses the basic ideas that the applet developers had in mind. These ideas 
are not explicit in the code, nor in the documentation (that we have seen). At 
the same time, the class invariant is one of the most complicated parts of the 
specification, and is sometimes needed to establish additional safety properties. 
The class invariant complicates the verification, because for each method it must 
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be shown that the invariant is maintained. But in the different verifications 
described below, only the LOOP approach actually used the entire invariant. A 
detailed description of the class invariant is therefore postponed to Section 5. 

The JML specification developed at this stage involved not only a class invari- 
ant, but also specifications for all methods in the applet class. A central method 
(as in any Java Card applet) is the process method: based on a case analysis us- 
ing the APDU’s class and instruction entries, it passes the card’s incoming byte 
sequence (called APDU for application data unit) to one of the private methods 
processSelectCmd, processReadRecord, processDeleteRecord, processPut- 
Data, or processAppendRecord. Additionally, the process method involves a 
debug option. The private methods called by process typically start with low- 
level byte operations on the APDU’s byte array, to perform appropriate checks 
or extract the relevant data. The associated JML specifications incorporate the 
corresponding checks, and are thus also low-level and rather verbose. 

The following actual fields of the SLB applet are most relevant: 

static final short O F F_I ) A r f A JN_R ECO R I > = (short)Ol: 

2 static final byte LENJi ECOR I )_LEN_BYTE = (byte)Ol; 

static final short MAXJtEN.OPTIONAL.DATA = (short)lO; 

4 static final short MAX_LEN_OPTIONAL_DATA_ANDJfEADER 
= MAXXEN.OPTIONALJ 3 ATA + ( short ) 3 ; 

6 static final short SIZE_OPTIONAL_DATA_BUFFER 

= (short) 3 * MA X E EN OPTION AT, DATA AND HEADER; 

8 // === Data entries 

byte by_NbRecords ; // number of existing data entries 

10 byte by_MaxNbRecord ; // max number of data entries 

byte by.MaxSizeRecord ; // max size of a record 
12 byte [] bya_OptionalData ; 

Object [] o.Records ; 

We introduced the following additional JML model fields, which are specification- 
only variables [10,11], typically used as convenient abbreviations or to provide 
a higher level of abstraction with respect to the actual fields. 

/ *@ public model final short OFF_DATAJN_APDU ; 

2 @ represents OFF_DATAJN_APDU 

<- (short) IS 07816 . OFFSET.CDATA ; 

4 @ public model final short ai d _of f _i n _d a t a ; 

@ represents aid _of f _i n _d at a 

e <- ( short ) ( OFF_DATAJN_RECORD + 5 ); 

@ public model final short aid_off_in_apdu ; 

8 @ represents aid_off_in_apdu 

<- (short ) (OFF_DATAJN_APDU + 5 ) ; 

10 @ public model short record.count ; 

@ represents record.count <— ( short )( by .NbRecords & OxFF ) ; 

12 @ public model short max.record.count ; 

@ represents max.record.count 

14 <— ( short )( by.MaxNbRecord & OxFF); 

@ public model short record.length ; 

16 @ // with first byte describing length of subsequent records 

@ represents record.length 

is @ <- ( short ) (LEN_RECORD_LEN_BYTE+(by_MaxSizeRecord&:OxFF ) ) ; 

@* / 
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Various methods will be discussed below in separate sections. 



2.2 Verification Aims 

SchlumbergerSema provided us with a list of security properties to be checked. In 
this paper, we focus on the property describing error prediction. It is requested 
that “No exception other than an ISOException should be thrown at toplevel as 
a result of invoking an applet entry point”. The following sections present the 
approaches of the different tools towards securing this property. 



2.3 Production and Evaluation 

Even though SchlumbergerSema is remarkably open in providing us access to 
actual production code, it is (understandably) secretive about many details, in 
order to protect its commercial interests. What we understand is that the applet 
under consideration has gone through the internal test and evaluation procedures 
within SchlumbergerSema before being sold to customers. We have no informa- 
tion about the nature and depth of these procedures, but we understand that 
there is no formal specification and verification involved. Hence, the verification 
methods described in this paper extend the internal approach at Schlumberger- 
Sema, and their results are therefore of interest in order to possibly improve the 
current practice. 



3 ESC/Java2 Approach 

ESC/Java 2 stands for Extended Static Checker for Java Version 2, a static 
checker which has originally been developed at Compaq SRC [12] and which is 
now being extended at the University of Nijmegen [3] . It has been applied to this 
case study in order to relate its checking approach to the verification approach 
followed by the other tools. ESC/JAVA2 is fully automatic (push-button). A 
drawback is that it is neither sound nor complete. Still, it provides valuable 
results which are demonstrated below. 



3.1 Checking Technique 

One approach of using ESC/JAVA2 is to add a JML specification to an applet 
and to apply ESC/JAVA2 to the specified applet. An alternative approach is 
to develop a specification interactively by invoking ESC/JAVA2 on an unspec- 
ified applet and by removing the warnings step by step by adding appropriate 
annotations. Remaining warnings can be confirmed or refuted by a verification 
system. This produces a lightweight specification which captures the applet’s 
requirements to run without errors. In a subsequent step, the user can develop a 
functional specification. The approach presented here is not intended to produce 
a functional specification automatically. 
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private void processDeleteRecord (APDU oApdu) { 

2 byte [] byaApdu = checklncomingData (oApdu , true, false); 

byte byMode = MODE_DELETE_UNSET ; 

4 switch (byaApdu [ IS07816 . OFFSET_P2]&;0x07 ) { 

case 0x00: // — modes delete by AID or refresh 

6 switch (byaApdu [ IS07816 . OFFSETJP1] ) { 

case 0x00 : 

s byMode = MODE_DELETE3Y_AID ; break; 

case 0x01 : 

10 byMode = MODE_DELETE_BY_REFRESH ; break: 

default : 

12 ISOException . throwlt ( IS07816 . SWJNCORRECT.P1P2 ) ; 

} break ; 

14 case 0x04: // — mode delete by record number 

byMode = MODE DELETE RY NUMBER ; break; 

16 default : 

ISOException . throwlt ( IS07816 . SWJNCORRECT.P1P2 ) ; 

18 } 

if ((byaApdu [IS07816 ,OFFSET_P2]> >3) != 1) 

20 ISOException . throwlt ( IS07816 . SW_FILE _NOT_FOUND ) ; 

byte [] byaRecordData = null; 

22 if (byMode = MODE DETETE RY NTJMREP) { /* ... */ } 

else if (byMode = MODE J3ELETE_BY_AID ) { 

24 for (byte i = 0; i < by.NbRecords ; i++) { 

byaRecordData = (byte [] ) ( o_Records [ i ] ) ; 

26 if ( Util . arrayCompare (byaApdu , IS07816 . OFFSET.CDATA , 

byaRecordData , ( short ) (OFF_DATAJN_RECORD+6) , 
28 byaRecordData [OFF_DATAJN_RECORD+5] ) = 0) 

{ /*■•■*/ } 

30 } 

} else if (byMode = MODEJ)ELETE_BY_REFRESH) { /* ... */ } 

32 } 



Fig. 1. SLB applet, method processDeleteRecord (slightly shortened) 

requires oApdu != null && oApdu . _APDU_state = 1; 

2 signals ( ArraylndexOutOfBoundsException u) 

(\exists short i; (0 <= i && i < by.NbRecords ) => 

4 ( ( short ) ( IS07816 . OFFSET.CDATA + 

((byte [] ) ( o.Records [ i ] ) ) [ OFFJDATA JN JIECORD + 5 ] ) 

6 > oApdu . buffer . length )) ; 

signals ( APDUException a) true; 

8 signals (ISOException i) true; 

Fig. 2. Lightweight ESC/JAVA2 specification of processDeleteRecord method 



3.2 The processDeleteRecord Method 

This section introduces the method processDeleteRecord of the SLB applet. 
Figure 1 shows part of the method’s source code. During the project, ESC/ 
Java 2 has been applied to the unspecified SLB applet in order to check the se- 
curity property described in Section 2.2. We interactively generated a lightweight 
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/ *@ requires src != null &fc srcOff+length <= src . length && 

2 @ dst != null &fc dstOff+length <= dst . length && 

@ srcOff >= 0 &fc dstOff >= 0 && length >= 0; 

4 @ signals ( NullPointerExcept ion ) s r c null || dst=null : 

@ signals ( ArraylndexOut OfBoundsException ) length < 0 
6 @ || srcOff <0 || srcOff+length > src . length 

@ || dstOff <0 || dstOff+length > dst . length ; 

8 @*/ 

public static final / *@ pure @* / byte arrayCompare ( byte [ ] src , 
10 short srcOff, byte[] dst, short dstOff, short length) 

Fig. 3. Method Util . arrayCompare () : Excerpt of JML specification 



specification (see Fig. 2) which captures all conditions that are required by the 
method to run without exceptions. It is especially interesting that ESC/JAVA2 
also points out some possible exceptions: APDUExceptions and ISQExceptions, 
which can be triggered from outside the applet. For example, the method 
APDU. setlncomingAndReceive, which is invoked in checkincoming Data (see 
Fig. 1, line 2), throws an APDUException if an I/O error occurred. These ex- 
ceptions cannot be avoided by setting up requirements to the method, which is 
clear from the generated specification: it states that these exceptions are thrown 
unconditionally (see Fig. 2, lines 7-8). They must explicitly be caught in the 
applet or allowed at the top level. 

Another reported exception is an Array IndexOutOfBoundsExcept ion which 
can occur in the call to Java Card’s Util . arrayCompare method (see Fig. 1, lines 
26 - 28). This method’s last parameter accepts the length of the interval in which 
the two arrays are compared. If this length is negative or too large, or if one of the 
offsets passed as arguments are too large, an ArraylndexOutOfBoundsException 
is thrown (see Figure 3). Section 4 treats the verification of this exception. 



4 Jive Approach 

Jive is a verification system developed at the Universities of Hagen and Kaisers- 
lautern. It is an interactive Hoare logic theorem prover with a special graphical 
user interface that uses an associated general purpose theorem prover (the user 
can choose between Isabelle/HOL [17] and PVS [16]). Internally, Jive operates 
on Diet Java Card, a desugared subset of Java Card which is very close to the 
original language. For the verification, a Hoare-style programming logic is used. 
The pre- and postconditions of the Hoare triples are given in a predicate logic 
notation. The ability to read JML specifications is currently being added. 

Proofs are performed by applying the Hoare rules - either manually or via so- 
called strategies which are Java programs that automatically apply several Hoare 
rules. Predicate logical statements over the pre- and postconditions (usually 
implications that stem from strengthening or weakening steps performed in the 
Hoare logic) are proven interactively in the associated prover. 
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One of Jive’s main strengths is its dedicated user interface. At all times, the 
user has full visual control over the whole proof process. A description of Jive’s 
architecture is given in [14]. 

4.1 Verification Technique 

In order to prove the given security property with Jive, one needs to pro- 
vide a specification that describes the absence of any exception other than an 
ISOException or APDUException in the poststate of the process method. 

Two techniques can be used to prove such a specification. The “standard” 
approach is to perform a backward proof by starting at the method implemen- 
tation and the given specification and by developing a proof by applying the 
Hoare-logic rules in backward direction, e.g. by using a weak(est) precondition 
generation strategy [18]. This approach is useful if there is nothing known about 
the correctness of the code. But if one already suspects an error in the code, 
another approach comes in handy: the assertion-supported forward proof. In this 
approach an assertion is inserted into the code which can be pushed through 
the code [19], again e.g. by means of a weak(est) precondition mechanism. This 
technique will be explained in more detail below. 

4.2 The processDeleteRecord Method 

To verify the exception in the method processDeleteRecord which was indi- 
cated by ESC/JAVA2 (see Sect. 3), we use the assertion-supported forward proof 
that was briefly sketched above. This strategy allows us to insert an assertion 
just before a statement s which is suspected to throw an exception. This as- 
sertion is then propagated to the beginning of the method body by means of 
weak(est) precondition generation. There are two possibilities for the assertion: 
One can either insert a formula P ass which is fulfilled by all states that do not 
raise an exception at s, or one can insert a formula Pf ss which is fulfilled by all 
states that definitely throw an exception at s. These formulae are propagated to 
preconditions P ca i c and Pf a j c , respectively. How do these generated preconditions 
relate to the precondition P spe c which is part of the method specification? 

Let us regard the first case. We know that if the precondition P ca i c holds, then 
no exception can occur at s. If P ca i c is a weakest precondition, i.e. if there are 
neither loops nor method invocations in the code before s, then the implication 
Pspec =t- Pcaic must hold, otherwise we know that an exception can occur at s. If 
Pcaic is not weakest, we can still try to prove the implication P spec => P ca i c - If it 
holds, we know again that no exception can occur, but if it does not hold, we do 
not know anything. We can only assume that P spe c may be too weak and should 
be strengthened (e.g. by adding P ca i c ). Thus, if we suspect that an exception 
occurs at s, and if there are loops or method invocations in the code before 
s, this may not be a good strategy because we might not get a usable result. 
Therefore, let us take a look at the second case. We know that each state which 
fulfills the formula Pff a i c is guaranteed to raise an exception at s. Therefore, we 
need to find a state S that fulfills both the given precondition P spec and the 
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generated precondition P^ a i c , in other words, the formula P spec (E) A P^ alc (S) 
must be valid. The state S is called a counterexample to the assumption that 
no exception is thrown at s. 

Regarding the processDeleteRecord method and the ArraylndexOutOf- 
BoundsException that ESC/Java 2 reported, this means that the assertion 
Pass’ which guarantees for all fulfilling states that an exception is thrown in 
the subsequent statement, contains the following: 

IS07816 .OFFSET.CDATA + byaRecordData [OFF_DATAJN_RECORD+5] 

2 > byaApdu . length 

Here, it is easy to construct a counterexample as the array byaRecordData can 
contain arbitrary data (see Section 3); therefore, we use the second strategy to 
verify the possible occurrence of an exception. A more detailed description of 
the methodology can be found in [19]. 



5 LOOP Approach 

After the initial phase described in Section 2 in which the specification was writ- 
ten, the verification with the Loop tool started 2 . This resulted in a number of 
changes in the specification: First, only during actual verification is the speci- 
fication really tested. A small number of subtle mismatches was found, leading 
to improvements in the specification. Second, the specification was optimised in 
its formulation to make it more suitable for verification. For instance, method 
calls were removed from specifications and replaced by explicit descriptions. This 
lowers the level of abstraction, but facilitates the verification with the LOOP tool. 

In Section 2 we have already seen part of the classwide JML specification, 
namely the model fields. This part will be extended first with the invariant. Then, 
Subsection 5.2 will describe the specification and verification of one method in 
greater detail. The class invariant that we formulated is as follows. 

/*@ invariant 

2 @ bya.FCI != null && bya.FCI . length = 23 &fc 

@ LENJtECORD.LEN_BYTE + DEF34AX_ENTRY_SIZE 
4 @ >= aid_off_in_data + 1 && 

@ LENJtECORD.LEN_BYTE <= OFF_DATAJN_RECORD 

6 @ 0 <= by.NbRecords &fc 0 <= by.MaxNbRecord 

@ 0 <= record.count &fc record.count <= max.record.count &fc 

8 @ 0 <= record-length && record-length > ai d _o f f _i n _d a t a &fc 

@ bya_OptionalData != null &fc o_Records != null && 

10 @ bya.OptionalData . length = SIZE_OPTIONAL_DATA_BUFFER && 

@ o_Records . length = max.record.count &fc 
12 @ (\forall short i; 0 <= i &fc i < max.record.count => ( 

@ (i >= record.count && o.Records [ i ] = null) 

14 @ ( i < record.count && o.Records [ i ] != null && 

@ o.Records [ i ] instanceof byte[] &fc 

2 At Nijmegen the (original) ESC/ Java tool was not applied to the applet, because 
the invariant (involving a complicated universal quantification) was too difficult to 
be handled by ESC/ Java. 
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24 @* / 



(( byte []) o.Records [ i ]). length = record_length && 
(( byte []) o.Records [ i ])[ aid _o ff.i n _d at a ] >= 0 && 

( ( byte []) o.Records [i ]) [ aid_off_in_data] < 
record.length — aid_off_in_data &fe 
((( byte []) o.Records [ i ])[ 0 ] != 0 => 

OFF_DATAJN_RECORD + 

((( byte []) o.Records [ i ])[ 0 ] & OxFF) 

<= record.length )))); 



The part of this invariant before the forall-quantification makes the bounds of 
the various (model) fields explicit. The forall-assertion describes the directory 
o_Records as an appropriate 2-dimensional array of bytes. It contains informa- 
tion that is not explicit in the code nor in the associated comments (provided by 
SchlumbergerSema), but was crucial for the proper understanding of the applet. 



5.1 Verification Technique 

The Loop tool is a compiler that takes Java+JML input and translates it to log- 
ical theories for the PVS [16] theorem prover. The generated PVS-theories incor- 
porate the resulting proof obligations: each JML method specification becomes 
a PVS predicate that must be proven for the associated translated method. 
See [9] for a recent overview and further references. These translated method 
specifications incorporate the class invariants in their pre- and postconditions. 

The actual verification happens in the backend theorem prover PVS. A user 
interacts with PVS by typing appropriate proof commands to guide the theorem 
prover. High level strategies are available, providing much automation. 

Typical of the Loop tool is the use of a shallow embedding: Java programs 
become actual functions in PVS, on the basis of an underlying semantics. These 
functions can be evaluated symbolically, corresponding to execution in Java. The 
LOOP verifications can take place in different ways. 

— Symbolic evaluation (aka. semantical proof). This can be very efficient in 
proofs, but only works for simple Java program fragments, not involving 
iterations (such as while and for loops). 

— Hoare logic [8]. In this way one can step through the Java code, at each 
point proving appropriate assertions. This provides more abstraction, but 
has the disadvantage that the user has to explicitly provide the intermediate 
assertions. However, this works well for larger method bodies, because they 
can be broken up into smaller manageable parts. The intermediate assertions 
can be written directly in JML, and are also translated by the LOOP tool. 

— Weakest precondition reasoning [7]. It provides several (forward and back- 
ward) strategies to automatically prove assertions for code fragments. This 
works well for relatively small pieces of code, and can thus be combined 
efficiently with Hoare logic. 

The fact that the entire Java+JML input is represented in PVS - and not bro- 
ken up by the translation tool - has both advantages and disadvantages: an 
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advantage of breaking up the proof goals inside PVS is that the rules for do- 
ing so (coming from Hoare and WP logic) are provably sound; a disadvantage 
is that size becomes an issue. Indeed, in the applet verification we found that 
the bottleneck in the verification was the theorem prover PVS. It has prob- 
lems dealing with the large proof goals resulting from the larger methods (esp. 
processAppendRecord and processDeleteRecord). Currently, these scalability 
problems are being discussed and solved with the PVS development team. 

One recent addition to the LOOP tool is the bitvector semantics [6] to han- 
dle Java Card’s bounded arithmetic (byte, short) in a precise manner. This 
semantics is heavily used in the SLB applet case study, with its many low-level 
operations on bytes (such as masking and shifting). 



5.2 The processAppendRecord Method 

The processAppendRecord method has the following header, with explanation 
as provided by SchlumbergerSema. 

/** Add a new record to the directory . The directory 
2 * is configured for a maximum number of directory entries 

* (set in the install command) 

4 * Entries once added can be removed, corresponding space can 

* be re— used again . ... 

6 */ 

private void processAppendRecord (APDU oApdu) { ... } 

The first step of the method is to put the byte array contained in the parameter 
APDU into a local variable byte [] byaApdu. The contents of this byte array are 
then examined, to see if they contain the right values to append a record (also 
contained in this byte array) to the directory (o_Records). If such an examination 
does not provide a positive result, an ISOException is thrown. These exceptions 
show up in the method’s JML method specification, as signal clauses. 

As part of these examinations an AID lookup is performed, of the form: 

if ( JCSystem . lookupAID ( byaApdu , ADF_OFFSET, 

2 byaApdu [ ADFXEN.OFFSET ] ) = null) 

ISOException . throwlt ( IS07816 . SW-CONDITIONS.NOT23ATISFIED ) ; 

In the verification of this code fragment the method specification of lookupAID 
from the API class JCSystem is used. This specification looks as follows. 

/ *@ public behavior 
2 @ requires true ; 

@ assignable \nothing; 

4 @ ensures true ; 

@ signals ( NullPointerException ) buffer = null: 

6 @ signals ( IndexOutOfBoundsException) 

@ offset <0 || length <0 || 

8 @ offset + length > buffer . length ; 

@* / 

10 public static AID lookupAID ( byte[] buffer , short offset , 

byte length ) 
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We see that an IndexOutOfBoundsException is thrown in case the parame- 
ter length is negative. During the verification of the processAppendRecord 
method we were not able to prove that this requirement holds for the byte value 
byaApdu [ADF_LEN_OFFSET] . Indeed, this requirement is not checked during the 
examinations at the beginning of the method. This is a bug: an APDU sent 
to the card can generate an exception that is not caught, and thus cause the 
application to halt, with status word “no precise diagnostic” 3 . However, this is 
not a security breach, because the applet remains in a consistent state, since the 
invariant still holds when such an exception appears. 

A similar bug shows up later on in the code: 

for (byte i=0 ; i <by_NbRecords ; i++) { 

2 byaRecordData = ( byte [ ] ) ( o_Records [ i ] ) ; 

if (( byaRecordData [ 0 ] != 0x00) // if not previously erased 

4 && Util . arrayCompare (byaApdu , ADF.OFFSET, byaRecordData, 

( short ) (OFF_DATAJN_RECORD+6) , byaApdu [ ADF XEN.OFFSET ] ) 
e =0) 

ISOException . throwlt ( IS07816 . SW-CONDITIONS.NOT23ATISFIED ) ; 

We see that the arrayCompare method from Java Card’s Util class is called. 
Its last parameter describes the length of the comparison interval (in two byte 
arrays). As we have seen in Section 3, if this length is negative or too large, an 
IndexOutOfBoundsException is thrown. This may actually happen in the applet 
because there are no appropriate checks on the value byaApdu [ADF_LEN_0FFSET] 
of the incoming APDU. 

In conclusion, these two bugs appear in the JML specification of the method 
processAppendRecord in the fragment: 

@ signals (IndexOutOfBoundsException) // This is a real bug! 

2 @ ( o Apdu . b u f f e r [ ADFXEN.OFFSET ] < 0 // for lookupAID 

@ || oApdu . buffer [ ADF_LEN_OFFSET] >= 

4@ record_length — ai d _o f f _i n _d at a ) // for ArrayCompare 

These bugs were discovered because the proof could not proceed at the above 
mentioned program points. 



6 Krakatoa Approach 

6.1 Verification Technique 

The Krakatoa tool [13] proceeds roughly as follows: from the JML-annotated 
source code of the API, and the program in consideration, and some method 
in that program, source scripts for the COQ proof assistant [20] are gener- 
ated automatically. They provide a modeling of the Java memory heap for 
the program (depending on the collection of classes and fields); COQ defini- 
tions corresponding to the specifications of all constructors and methods of the 
program; a set of proof obligations, which are not in fact generated directly 

3 We have been able to recreate this exception on an actual smart card running this 
applet. It was the first bug found in the course of this case study. 
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but by using an external tool called Why [4,5]; and a so-called validation of 
the method considered, that is a COQ program equivalent to it, of the form 
\/args \/heap inl pre => Bresult 3 heap outl post. 

The application of the Krakatoa approach to the SLB applet case study took 
some benefit from the achievements of the Loop team. We actually used JML 
specifications they wrote both for the Java Card API and the applet, performing 
only a few minor changes to optimise the specifications for the Krakatoa tool 
as well as to avoid some ad hoc additions related to the LOOP tool. We focus 
here on the processPutData method. 



6.2 The processPutData Method 

An excerpt of the annotated source of this method is shown in Figure 4. The 
changes (w.r.t. Loop specifications) we made are marked by appropriate com- 
ments. The first addition is in the precondition, line 2 of the listing. It appears 
to be needed for performing the proof of the normal postconditions, because oth- 
erwise oApdu. buffer could be modified, and everything would go wrong. After 
discussion with the Loop team, it appears they did not need this assumption be- 
cause they were able to derive it from the JML class invariant of the APDU class: 
they put a very large minimal bound for the length of APDU buffers, so that 
these arrays can be provably different just because their lengths are different. 

The second addition is in the modifiable clause on line 4 of the listing: men- 
tioning ISOException. systemlnstance ,theSw[0] is needed because this lo- 
cation is modified when an ISOException is thrown. This was not required 
by LOOP, because, as before, they simplified the JML specifications of the 
ISOException class, to get rid of such annoying and essentially irrelevant details. 

The third change, line 7 of the listing, is the use of the pure method get Index 
to replace the expression >>4 used in Loop, which is OK only because of the 
specific values of the TAG_* constants. For LOOP it is more convenient to have 
executable specifications because of its symbolic evaluation feature, but with 
Krakatoa it is better to use more abstract specifications: we introduced a JML 
pure method get Index to capture the logical behavior of the switch statement. 

The last change, lines 17 -21 of the listing, is an annotation for the switch 
statement, which is not standard JML but an extension allowed in Krakatoa. 
This is because we met scalability issues: the amount of generated COQ source 
is quite large; and much effort has been made to reduce such problems. For 
instance, the annotation for the switch statement above reduced the size of the 
proofs with a factor four, because in some sense it factorizes all four cases of 
the switch. This clearly suggests that such an extension of JML is useful for 
theorem proving (indeed this extension is now under consideration). 



7 Results and Experiences 

In this case study, several exceptions were detected by the LOOP tool and 
ESC/JAVA2. These are SystemExceptions, ISQExceptions, APDUExceptions, 
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/*@ requires oApdu != null 

2 @ && byaOptionalData = bya_OptionalData 

@ && byaOptionalData ! = oApdu . buffer ; //added 

4 @ modifiable byaOptionalData [*] , 

@ ISOException . systemlnstance . theSw [ 0 ] ; // added 

6 @ ensures (\forall short i; 0 <= i 

@ i < sh (oApdu . buffer [IS07816 . OFFSETXC] ) + 3; 

8 @ byaOptionalData [ getlndex // instead of »4 with LOOP 

@ (Util . getShort (oApdu. buffer , IS07816 . OFFSET.P1 ) ) 

10 @ * MAX_LEN_OPTIONALJDATA_AND_HEADER + i ] 

@ = oApdu. buffer [IS07816 .OFFSET_Pl+i ]) ; 

12 @ signals (ISOException e) true; 

@ signals ( APDUException e) true; 

14 @* / 

private void processPutData (APDU oApdu, byte [] byaOptionalData) 
16 { ... (some verification of input data skipped) 

byte byindex = (byte)O; 

is /*@ assignable ISOException . systemlnstance . theSw [ 0 ] ; 

@ ensures 0 <= byindex && byindex <= 2 
20 @ byindex == getlndex ( Util . getShort (oApdu . buffer , 

@ IS07816 . OFFSET_Pl ) ) ; 

22 @ signals (ISOException e) true; 

@* / 

24 switch ( U til . get Short ( byaApdu , IS07816 . OFFSET_Pl )) { 
case TAG_FCIJSSUER_DISCRETIONARY_DATA : 

26 byindex = 0 ; break ; 

case TAGJSSUER.CODE.TABLEJNDEX : 

28 byindex = 1 ; break ; 

case TAGJANGUAGEJPREFERENCE : 

30 byindex = 2 ; break ; 

default 

32 ISOException . throwlt (IS07816 . SWJNCORRECT_PlP2 ) ; 

} 

34 U t il . arrayCopy ( byaApdu, IS07816 . OFFSET_Pl , byaOptionalData, 
(short ) ( byindex * MAX_LEN_OPTIONALJDATA_AND_HEADER) , 
36 ( short ) ( shLC + (short ) 3 ) ) ; // +3 for TAG(2) and LEN(l) 

} 

38 

/ *@ ensures 0 <= \result &fc \result <= 2 
40 @ && (tag = TAG_FCIJSSUER_DISCRETIONARY_DATA 

=> \ r e s u 1 1 = 0 ) 

42 @ && (tag = TAGJSSUER.CODE.TABLEJNDEX => \ result = 1) 

@ && (tag = TAG_LANGUAGE_PREFERENGE => \result = 2); 

44 / 

private static /*@ pure @* / byte getlndex ( short tag); 

Fig. 4. Excerpt of processPutData method, annotated 



TransactionExceptions and ArraylndexOutOfBoundsExceptions. Schlumber- 
gerSema’s security policy only accepts ISOExceptions at the top level. But 
SystemExceptions, APDUExceptions and TransactionExceptions are inavoid- 
able in the applet because they can be initiated externally (see Sect. 3.2 for an 
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example). Here, the two tools clearly pointed out that SchlumbergerSema’s secu- 
rity policy is too strict. But of course, the ArraylndexOutOf BoundsExceptions 
are the most interesting exceptions. The Loop and Jive tools verified that these 
exceptions may occur in the processAppendRecord and processDeleteRecord 
methods because the applet uses data which has been passed from the card ac- 
cepting device (CAD) to the applet in an APDU to index an array, and which 
has not been checked to be within the array bounds. Usually, this does not pose 
a problem, but if the applet is being attacked, malformed APDUs will be likely 
to be sent to it, which should not cause an exception to occur. To our knowl- 
edge, this exception cannot be used to exploit the applet nor to permanently 
damage the contained data. But the applet programmers would nevertheless be 
well advised to remove this cause of abrupt termination. 

The processPutData method, as it is annotated in Figure 4, has been fully 
verified by the Krakatoa tool. It was shown that no exception can be thrown 
other than ISOException or APDUException, and that the method satisfies its 
normal postcondition and preserves a class invariant. 

Writing the specifications was a substantial part of the effort. Ideally, the 
specifications are already there, written by the programmers themselves. How- 
ever, just writing specifications without checking them may lead to mismatches. 
Part of this case study’s success is due to the support of JML by all tools ex- 
cept JlVE; only small changes had to be performed to adapt to Krakatoa and 
ESC/JAVA2. 

This case study has shown that the Loop approach is capable of analyzing 
a non-trivial amount of Java Card source code (in the order of hundred’s of 
lines), and to detect errors that had previously gone unnoticed. Krakatoa also 
demonstrated its ability to prove non-trivial properties of Java Card applets. 
This is clearly a success. 

For Krakatoa and Loop, performance and scalability bottlenecks occurred 
within the backend theorem provers Coq and PVS, respectively. They slowed 
down the effort considerably. Improvements are currently under investigation. 

The LOOP and Krakatoa approaches require user interaction with PVS 
and Coq provers respectively, and knowledge of both the back-end prover and 
the Java modeling introduced by the respective tool is mandatory. But for an 
experienced user, proving the obligations generated from one method is not so 
hard: indeed, much of our time has been spent on improving the specification, the 
modeling, etc. to make proofs easier. Nevertheless, more automation of proofs is 
required via dedicated strategies/tactics in the back-end prover. Also, the option 
of further integration of handling of proof obligations by either an automated 
prover like Simplify (used by ESC/JAVA2) or an interactive prover (like Coq or 
PVS) is currently under study. 

The validation of suspected errors (e.g. those detected by ESC/ Java2) is not 
as costly as a full verification. Although a partial verification as e.g. performed 
by the JlVE tool does not guarantee that the areas that ESC/JAVA2 reports as 
correct are indeed error-free, it still is a recommendable approach to software 
verification because the tradeoff between cost and correctness that comes with 
it seems to be fair enough. 
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It is difficult to give exact measurements of time because this case study was 
used to optimize the tools, so that it is hard to tell what the pure verification 
time is. Additionally, the JML specifications had to be written in the beginning 
and improved during verification. All we can say that if no major problems arise, 
then the verification of individual methods is a matter of days. 

8 Conclusions 

The SLB applet case study described in this paper has pushed the development 
of the Java verifiers (Jive, Loop, Krakatoa) to make them powerful enough 
to handle non-trivial source code. (The development from ESC/ Java to ESC/- 
Java 2 is independent.) Moreover, it has led to a unification in the area and a 
common focus on JML as specification language. 

The semantical complexity of languages like Java and JML means that code 
verification is still very complicated and requires a substantial amount of user 
interaction. Nevertheless, the current tools are capable of detecting non-trivial 
bugs that were not spotted with conventional techniques (testing and code in- 
spection). The case study has made it clear where the complexities are, and 
where improvements are needed. Here is a brief analysis. 

Static checking with ESC/JAVA2 has become a very powerful push-button 
technique that is so simple to use that good Java developers should be able to use 
it. This means that they can write their own JML specifications together with 
the implementation, and check it while they are developing code. The theorem- 
prover based verification techniques are still complicated and labor-intensive, 
so that they should be reserved for the cases that ESC/JAVA2 cannot handle, 
probably by people in research departments or outsiders. The positive feedback 
of SchlumbergerSema on this case study envisages an approach along these lines. 

As an aside, separate from verification: SchlumbergerSema (and other com- 
panies like Gemplus) are enthusiastic about the use of JML. They see as one of 
the next challenges to relate their high-level security requirements to the rela- 
tively low-level specifications in JML. 

It is in the nature of Java Card applets that they communicate with the 
outside world via byte sequences (in APDUs). As a result, much of the imple- 
mentation and specification involves low-level details that are hard to write and 
easy to get wrong. A more abstract approach is badly needed, for instance based 
on Java Card RMI (see also [15]), as has recently been added in Java Card 2.2. 

When we compare the verification tools used in this paper 4 we see two fun- 
damental differences: First, Loop and Krakatoa are front-ends to theorem 
provers in which the interactive verification takes place on the translated pro- 
gram code. In contrast, the user of the Jive tool spends most of the time inter- 
acting with the original program code. Second, verifications with the Krakatoa 

4 Besides the three verification approaches used in this paper there is also the deep 
embedding of Java into Isabelle/HOL [17] developed by the VerifiCard partner in 
Munich. Such a deep embedding is ideal for proving meta-properties (like type- 
safety), but too complicated for the verification of concrete programs. 
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and Jive tools decompose the proof goal into many separate verification condi- 
tions. The Loop tool generates one single proof obligation, which is decomposed 
(using provably sound rules) within the back-end theorem prover. The first ap- 
proach leads to very many small obligations, and the latter to one big obligation. 
Both approaches may lead to too much data to manage. Among these alterna- 
tive approaches there is (maybe unfortunately) not a single one that emerges as 
“best”. An interesting perspective is to be able to make these tools, including 
ESC/Java 2, cooperate. 

In conclusion, we see a bright future for Java source code verification (based 
on JML specifications) in a 2-step approach, where theorem-prover based verifi- 
cation should be smoothly integrated with static checking, and be used to handle 
the difficult left-overs (like in [1]): Especially methods with loops or recursion or 
sources of remaining warnings are likely to still contain errors and are therefore 
good candidates for full verification. 
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Abstract. We propose a new approach to interprocedural analysis and 
verification, consisting of deriving an interprocedural analysis method 
by abstract interpretation of the standard operational semantics of pro- 
grams. The advantages of this approach are twofold. From a methodolog- 
ical point of view, it provides a direct connection between the concrete 
semantics of the program and the effective analysis, which facilitates im- 
plementation and correctness proofs. This method also integrates two 
main, distinct methods for interprocedural analysis, namely the call- 
string and the functional approaches introduced by Sharir and Pnueli. 
This enables strictly more precise analyses and additional flexibility in 
the tradeoff between efficiency and precision of the analysis. 



1 Introduction 

We consider the interprocedural verification of invariance properties of imper- 
ative programs. The applications we have in mind are automated debugging 
[4, 14] or automatic test selection [25] , which may require precise and complex 
analyses. These are flow- sensitive (the analysis needs to take conditionals into 
account accurately), attribute- dependent (attributes (or properties) of variables 
are inter-related), and may require the use of infinite or even infinite- height 
lattices, in particular for the analysis of the properties numerical variables. 

Our ambition is to design a method which is able to infer precise facts on 
the possible call-stacks of programs (and not only on the possible environments 
lying on top of the call-stack) , and which can reuse existing abstract interpreta- 
tion techniques and implementations available for intraprocedural analysis. For 
debugging applications, we would like to be able to answer questions like: 

Being in procedure P with environment ep, and assuming being called 
successively by R and Q with x=y, is it possible to enter procedure 5? 

Formally, this amounts to ask whether an execution path of the form 

{cr,'?) ■ (c Q ,x = y) ■ (c P ,e P ) -> * F-(c s ,?) 

exists. Such an automatic state reaching feature has already been implemented 
in a debugger for reactive programs [14]. 



C. Rattray et al. (Eds.): AMAST 2004, LNCS 3116, pp. 258-273, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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We first present our method, before discussing existing approaches to inter- 
procedural analysis and some of their limitations for the applications we have in 
mind. 

Our method. We start from the standard (small-step) operational semantics 
of imperative programs and derive in two distinct abstraction steps an imple- 
mentable analysis. Since we aim the verification of invariance properties, the 
property lattice L is the powerset of states p(S). The difficulty in interproce- 
dural analysis is that a state is an unbounded stack of activation records 1 , i.e. 
pairs of control points and local environments, so that the state-space has the 
following form: S = Act + with E + = Oi>\E' 1 denoting the Kleene operator on 
a set E. This means that there are two sources of infinity in the lattice L : the 
unbounded length of stacks, and the cardinality of the domain Act, considered 
as infinite as soon as there are numerical variables or recursive data structures. 

The first abstraction abstracts the collecting semantics - which manipulates 
(co-)reaclrable sets of stacks of activation records - to a semantics manipulating 
sets of extended activation records. This stack abstraction, which deals with 
the first source of infinity, is independent from a second, more classical data 
abstraction, which abstracts sets of extended activation records in one of the 
many computable abstract lattices that are available for intraprocedural analysis, 
in order to deal with the second source of infinity, cf. Fig. 1. 




Collecting Stack Data 

semantics abstraction abstraction 

Fig. 1 . Analysis scheme 



The stack abstraction defines the interprocedural analysis method itself but 
does not lead directly to an effective analysis. Rather, it just simplifies the con- 
crete lattice of sets of stacks into sets of simpler objects, for which computable 
abstract lattices already exists. Those need just to be equipped with a correct 
abstraction of procedure calls and returns operations in the stack abstraction 
lattice A s , in order to obtain an implementable interprocedural analysis. 

Existing approaches and some of their limitations for our applications. Inter- 
procedural analysis methods have been widely studied and many of them can 
be classified as one of two classical approaches. We review in section 6 methods 
that do not fit in this classification. The functional approach [6, 28, 19] uses a 
denotational semantics of the analysed program and proceeds in two steps. The 
first step computes the predicate transformers associated with the procedures 
of the program, and the second step uses them to propagate an input predicate 
along the execution paths, to obtain the predicates holding at each control point. 
Some drawbacks of this approach are the following: 

We assume in this paper that there are no global variables. 



l 
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1. Predicates holding at control points are replaced by predicate transformers, 
which are more complex objects. This new viewpoint forbids the direct reuse 
of intraprocedural analyses (which use predicates). 

2. The call-stack of the original program disappears, so no property can be 
specified on it. 

The operational approach , generalising the “call-string approach” of [28] , con- 
sists of adopting an operational semantics for programs. Fixpoint computation 
proceeds as in intraprocedural analysis, i.e. by propagating a predicate along 
execution paths. However, (an abstraction of) the call-stack has to be taken into 
account. The general abstraction scheme for call-stacks consists of using “to- 
kens” to abstract stack-tails, and to label current activation records by them. 
These tokens represent the calling context of the current activation record [28, 
18]. We bring a solution to the main limitations of this approach, namely: 

— Tokens are used as labels. They are essentially enumerated and are not given 
any structure (as for instance a lattice structure). 

— A notable consequence is that the set of tokens should be finite in practice, 
which means that the abstraction of stack-tails is very rough. 

From a more synthetic point of view, both approaches lead to context-sensitive 
analyses. The functional approach takes into account the data part of the calling 
context of a procedure, whereas the operational approach focuses mainly on the 
control part. From this point of view, our stack abstraction enables an effective 
analysis which is both data and control context-sensitive. 

Contributions. Using the principles of abstract interpretation, we unify two main 
interprocedural analysis methods and give correctness and optimality proofs 
with a minimal number of concepts. We provide a method which is both data 
and control context-sensitive, thus strictly more precise. Our approach enables 
backward analysis and its intersection with forward analysis. Finally, it facilitates 
implementation issues by clearly separating stack and data abstractions. 

Outline. Section 2 presents the considered program model and its semantics. 
In Section 3 we revisit the functional approach with a first stack abstraction. 
We show the similarity of the two methods and discuss some advantages of our 
approach. In Section 4 we refine the previous abstraction by using call-strings, in 
order to subsume the call-string and the functional approaches. This allows us to 
accurately specify the above-mentioned debugging problem. Section 5 discusses 
the data abstraction step, in order to derive an effective analysis from a stack 
abstraction. Related work is described in Section 6 and Section 7 concludes. Due 
to the lack of space, we have omitted the proofs. They can be found in [16]. 

2 Program Model and Standard Semantics 

We consider a simple imperative programming language with non-nested proce- 
dures and value parameter passing (as in Java or Ml). We suppose that each 
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Table 1. Syntactic domains 



Var 

LVari, loc; 

Ini , fpi, 
Outi , fpo ; 

Gi = ( Ctrh,Ii ) 
Si, ei £ Ctrl* 
G = (Ctrl,/) 



Variables: Var = |J i LVan 
Local variables of procedure Pi 
Formal input parameters of Pi 
Formal output parameters of Pi 
Flow graph of Pi 
Entry and exit points of Pi 
Flow graph of the program 




CFG for the Factorial Program 



Table 2. Semantic domains 



v £ Value : values 

ti £ LEnvi = LVari — > Value : local environments for Pi 

e £ LEnv = (J ( LEnvi : local environments 

(c, t) £ Act = Ctrl x LEnv : activation record 

P £ State = Act + : stacks/program states 



procedure has its own fixed set of variables, and do not consider global variables, 
which can be passed as additional procedure parameters. Similarly, programs are 
not restricted to programs manipulating scalar values: pointers and a memory 
heap can be modelled by adding to all procedures a special parameter modelling 
the memory heap. We require that formal input parameters are not modified. 
This is crucial to compute a relation between environments at the entry and any 
other point of a procedure (as in [28,19]), and this is not restrictive either, as 
they can always be copied into additional local variables. The main restrictions 
are thus the absence of exceptions or non-local jumps, variable aliasing on the 
stack (as it happens with reference parameter passing), pointers to procedures 
and procedural parameters. 

Program Syntax. The syntactic domains are summarised in Table 1. 

A program is defined by a set ( Pi)o<i< P of procedures. Since we specify the 
initial states of an analysis separately, there is no particular “main” procedure. 

Each procedure Pi = {LVari, Ini, Outi,Gi) is defined by its intraprocedural 
control- flow graph Gi and its sets of local variables LVari , formal input pa- 
rameters Ini C LVari and formal output parameters Outi C LVari. We note 
x = (x fl ), . . . ,x( ra )) vectors of variables. As vectors, the above-mentioned sets 
are written loc,. fpi, and fpo,. 

An intraprocedural control-flow graph is a graph Gi = {Ctrli, Ii) where Ctrli 
is the set of control points of Pi, containing unique entry and exit control points 
s i and ei. fi : Ctrli x Ctrli — > Inst labels edges between control points with two 
kinds of instructions: intraprocedural instructions (R) and procedure calls (y := 
Pj(x)), where x and y are the vectors of actual input and output parameters. 
Intraprocedural instructions are specified as a relation R C LEnv 2 describing the 
transformation of the top environment. We require the G, to be deterministic for 
procedure calls, i.e. if Ific, c') is a call then there exists no c" such that Ific, c") 
or {c" , d) is a call. 
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I(c,c') = (R) R(e, e') 


t(c, Sj) = (cally := Pj(x)> Vfc : €j (fpi^ 0 ) = e(x (fe) ) 

(Call) 

r-(c,e> -» r ■ {c, e) ■ {sj , ej) 

i c ) = ( ret y : = Fj(x)) e' = e[y( fc ) i-t- £j(fpo( fc) )] ^ ^ ^ 


r -(c, e) — » T- <c', e'> 
(Intra) 




r- (call(c), £> • (e,-, e,-> r-(c,e'> 



Fig. 2. SOS rules defining — > 



The interprocedural control-flow graph (CFG) G = {Ctrl, I) is constructed 
from the set of intraprocedural ones. Ctrl is defined as Ctrl = (Jo<i<p Ctrli and 
I is defined as the “union” (J. ; It , where all procedure-call-edges are removed and 
replaced by two edges usually called call-to-start and exit-to-return edges: 

h{c,d) ± (y := Pjjx)) h{c,d) = (y := Pj{x)) 

I(c, d) = Ii(c,d) I(c,Sj) = (cally := Pj(x)} 

I{ej,d) = (rety := P/(x)) 

Thus there are three kinds of instructions labelling edges of interprocedural 
CFGs: intraprocedural instructions (R), procedure calls (cally := Pj(x)) and 
procedure returns (rety := P,(x)}, see the factorial program beside Table 1. 

In the sequel, we use the following notations. For c £ Ctrl, c is a call-site to 
Pj if 3c' : I{c,d) = (call y := Pjfx)). proc(c) denotes j such that c £ Ctrlj. 

For any edge c - > c' , we define ret(c) = d and call (d) = c. 

Operational Semantics. The semantic domains are summarised in Table 2. 

The operational semantics is given by a transition system ( State ,— >). States 
are stacks r = (co, eo) • ■ • ■ • (c„, e n ) of activation records (i.e. pairs of a control 
point Cj and an environment ej). (c n , e n ) is the current activation record or top of 
T; the tail of T is T without its top, i.e. (co, eo) ■ • • • ■ (c n _i, e„_i). Environments 
map variables to values; their update is written e[x i— > u]. The transition relation 
— > C State x State is defined (in SOS-style) by the rules in Fig. 2. As long as a 
variable is not initialised, it holds nondeterministically any value in its domain, 
cf. rule (Call). As usual, — >* denotes the reflexive-transitive closure of — 

Standard Collecting Semantics. The forward collecting semantics describes 
the set of reachable states of a program. It is the natural choice for expressing 
and verifying invariance properties and is derived from the operational semantics 
by collecting the states belonging to executions of the program. We define the 
function reach : p(State) — > p(State) computing the states reachable from a set 
of initial states Xo as: 

reach(X 0 ) d = {q \ 3 q 0 £ X 0 , q 0 ->* g} 

It is also the least fix-point solution of X = X 0 U post{X) where the forward 
transfer function post is defined by post{X) = {q' \ 3 q £ X : q — » q 1 }. Ta- 
ble 3 gives the decomposition of post according to the transitions of the CFG, 
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Table 3. Forward transfer function post 




I (c,c ) 

i.e. post(X) = U ( c ,c )£ Ctrl X Ctrl Post(c — - — » c')(X). For X 0 ,X C S, we define 

def 

F 1 [X 0 ](X) = Xq U post(X). Since F[X 0 ] is monotone and continuous, Kleene’s 
fix-point theorem allows us to compute the forward collecting semantics by iter- 
ated application of F[Ao] starting from 0: 

reach(X 0 ) = lfp(F[X 0 ]) = U„> 0 (F[X„])"(0) 

The collecting semantics can also be considered backward, yielding the set 
of states X from which a given set of final states Xo is reachable. In this case 
we call X the set of coreachable states of Xo- We get the following definitions: 

pre(X) = {q \ 3q' e X : q -> q'} 
coreach(X 0 ) = lfp(G[AT 0 ]) with G[AT 0 ](A1) = X 0 U pre(X) 

Properties of the Stacks in the Standard Semantics. The assumption 
that formal input parameters are read-only variables induces strong properties 
on stacks which are the basis of our stack abstractions. A necessary condition 
for q = T- (c, e) to lead to q' = T • (c, e) • ( c\ e') (where c is a call site to P pr0 c(c )) 
is that the values of actual input parameters in e have to match those of the 
formal input parameters in e' . This is formalised by the following definition. 

Definition 1. (c, e) is a valid calling activation record (or valid,) for (c',e') if 

(i) c is a call site for procedure Pj: 3 j : c ' = s j A I(c,Sj) = (cally := P,-(x)); 

( ii ) actual and formal parameters are equal: Vfc : e(x^) = e'(fpi^). 

Extending Definition 1, we call a stack (co, eo) . . . (c n , e n ) consistent if (cj, ef) is 
valid for (cj+i,ei+i) (VO < i < n). From now on, we focus on consistent states 
and restrict State to its consistent subset. 

3 Revisiting the Functional Approach 

We present a first stack abstraction, which allows analysis results at least as 
accurate as the classical functional approach for forward analysis, but in addition: 

— It enables a more direct reuse of standard data abstractions (we manipulate 
environments and not functions from environments to environments). 

— Stacks can be rebuild by concretisation of abstract values. 

— Defining backward analysis is straightforward. 
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3.1 Stack Abstraction 



The main idea is to forget all about sequences of activation records in the stack, 
keeping information only on the activation records themselves. As already ob- 
served in a different context [19], we can nevertheless get accurate results. 

An abstract state Y = ( Yhd,Y t i ) is composed of two sets of activation records. 
Yhd represents top activation records, whereas Y t i is the collapse of all activation 
records in stack-tails. This leads to the following abstract domain: 

Af p(Acf) x p(Act) ( 1 ) 

which comes equipped with the standard lattice structure A^(C, U, n, T, _L) of a 
(smashed) Cartesian product of lattices. 

i ! 

We define the Galois connection p(State) t.. .' .> A?, with the abstraction 

a.* 

function oJ = {ct{d’ a ti) an d concretisation function 7 ^ defined by: 



{(co,e 0 ). . .(c„, e n )} 

7/: Y=(Y hd ,Y a ) 



U g 6 A- af (U}) 

( {(c„,e„)} , {{Ci,6i) I 0<*<n} ) 

{ (en? e n ) £ Yhd 
q = (co,e 0 ). • .(c„,e„) V0<i<n: (c^e^eYt; 

q is a consistent stack 



a hd g a th ers the t°P activation records, whereas a ^ collects all the other acti- 
vation records. To rebuild a stack from an abstract state, 7 ^ uses the notion of 
consistent stacks. Notice that (c, e) £ Y t i implies that c is a call site. 

The extensive function 7^0 of describes the information lost by A A If (co, eo) 
is valid for (ci, e'f) and e\ A e), we might have: 



(c 0 ,e 0 )-(ci,ei) £ ( 7 ^ oaf)^{(c 0 ,eo)-( c ij e i)) < c i 5 e i>}) 
£ { ( c o> eo) • (ci, ei), (ci,ei)} 



However, af ld (X) keeps exact information on top activation records, which is 
the only information computed by functional approaches. 

The main reason why we separate top activation records from those below 
in the stack is for defining properly an abstract backward analysis, and also for 
being able to perform a forward analysis from an non empty stack. 



3.2 Forward Analysis 

Abstract Postcondition post ? . To compute reachable states in the abstract 
domain, we need an abstract postcondition operator postf . Table 4 specifies 
postf , using the decomposition already used for post. We prove in [16] that 
postf is a correct approximation of post , i.e. postf □ a/ o post o 7A 

Only procedure returns need comment, since the stack contents before the 
call has to be recovered. [28, 18, 19] use for this purpose a function combine to 
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Table 4. Equations defining post* 



post f hd (c c')(Y) = { (c , t) | (c, e) G Y hd A f?(e,e')} 



POst f hd {c 



(call y:=Pj (x)) 



(3a) 

i)( Y ) = {{sj,ej)\{c,t) £Y hd A ej(fpif } ) = e(x (fc) )} (3b) 



P° st hd( e i <rety - Pj(x)> > c)(y) = Gc,e') 



(cal 1(c), e) G Yu A e(x (fc) ) =6j(fpi( fc) ) 
(ej,ej)€Y hd A e' = e[y w ^e.,(fpo( fc) )] 



(3c) 



, f, (call y:=Pj (x)) 

post J a {c ♦ 



i){Y) = Ya u {(c, e )Giy 



post* tl (c —> c)(Y) = Yti otherwise ( i is an instruction) 



(3d) 

(3e) 



combine the environment of the caller at the call site with the environment of 
the callee at its exit point. In Section 2, we noticed that T ■ (call(c), e) • (e ; , Cj) 
can be a successor of r -(call(c),e) only if (call(c),e) is valid for (ej,ej). So, 
for (ej. dj) G Yhd, (3c) selects the activation records (call(c),e) G Y t i valid for it. 
Then, the reachable activation record(s) at c are obtained by assigning return 
parameters to y. This is our combine operation, defined by abstraction of the 
concrete procedure return operation. 

Because the input parameters are frozen, at the exit point e d of a procedure 
Pj, the top of the stack (in Yhd) contains a relation 0j(fpi •, fpo •) between reach- 
able call and return parameters, defined by <f>j = {(x,y) | 3(ej,e) G Yhd '■ x = 
e(fpij)Ay = e(fpo J )}. Since (pj is the predicate transformer of Pj specialised on 
the reachable inputs, our handling of procedure returns can be seen as applying 
the predicate transformer of the callee to the valid calling activation records that 
are reachable in Yu at the call site. 

Correctness and Optimality. Transposing the notion of reachable states into 
the abstract lattice A* , we define F*[Yo](Y) = f Yo U post* (Y) and reac h f (Y 0 ) d ^ f 
lfp(F'f [Yo]) (VYo G A*). Since post * correctly approximates post , we deduce from 
abstract interpretation theory that we correctly approximate reachable states: 

Theorem 1 (Correctness). For any Y 0 G A* , reac h f (Y 0 ) □ a* oreacho"f-f (Yq) 

The fact that we incrementally build the predicate transformer of a procedure 
at its exit point together with [28] suggests that we could improve and get the 
best we can hope for with a Galois connection, that is 

reach ? o a* = a* o reach 

This means it doesn’t matter if we compute the fixpoint in the concrete lattice 
and then abstract the result, or directly compute in the abstract lattice. 

Since Theorem 1 implies reach ^ o a* □ a* o reach , we just have to prove 
the inverse inclusion. We show that Y = a* o reach(Xo) is a post-fixpoint of 
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Table 5. Equations Defining pre * 




post f, i.e. that post^(Y) C Y, under additional assumptions on X 0 . First, we 
require initial states to be one-element stacks, guaranteeing exactness of their 
abstraction. Second, we require that initial states/activation records belong to 
procedures that are never called; otherwise the abstraction might allow procedure 
returns even if there is no other activation record on the (concrete) stack. 
Under these conditions, we get: 

Theorem 2 (Optimality). Let Xq £ p(State) such that q £ Xq implies that 
q = (c, e) and that pro c(c) is never called by any procedure. 

Then reach-' o a? (X o) = a? o reach(X o). This implies that 

reach^ hd o a* (X q) = {(c,e) | 3 T: T-(c,e) £ reach(Xo)} 
reach/ tl o a/(X 0 ) = {(c, e) | 3 T, T' : T ■ (c, e) -T' £ reach (X o)} 

Whereas our analysis loses information on stack contents, we get exact results 
if we are interested only in the values held by variables at some control points 
(which is the case for many applications). 

As we relate our abstract semantics directly to the standard semantics, we get 
by Theorem 2 the Meet Over all Valid Paths property defined in [28, 19], without 
having to introduce the notion of interprocedural valid paths. Theorems 1 and 
2 are thus very similar to the optimality results in those papers. 



3.3 Backward Analysis 

Backward analysis is implemented in a similar fashion as forward analysis. Ta- 
ble 5 gives the definition of a correct approximation of pre in A? . By defining, 
for Yq,Y £ A , G f [Y 0 ](Y) = YqU pre? (Y) and coreac h f (Y 0 ) = lfp(G / [F 0 ]) we get 
the correctness of the analysis: coreach ^ □ a? o coreach o yU Here we do not 
have any optimality result, as formal output parameters are not frozen during a 
backward execution. But we could use a similar mechanism by duality. 
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3.4 Comparison with the Functional Approach 

Re-expressing the functional approach (c/. introduction) by abstracting the 
stacks of the concrete semantics presents some advantages. From a conceptual 
point of view, we manipulate environments instead of functions from environ- 
ments to environments. The relational character of the stack abstraction is in- 
herited from the relational character of the concrete semantics, induced by the 
freezing of the formal input parameters. 

From an algorithmical point of view, we merge the two hxpoint computations 
of the traditional functional approach to a unique hxpoint computation. Thus, 

— Our method is less compositional: we have to perform a new analysis for 
different initial states, whereas in the functional approach only the second 
hxpoint has to be computed again, as the predicate transformers associated 
with procedures are defined by the hrst hxpoint and do not depend on the 
initial states. 

— It may however be more accurate: indeed, we compute at the exit point 
of the procedures their predicate transformers specialised on their reachable 
inputs. As the functions post f and F^Yq] are not distributive, applying 
them on smaller abstract values may prevent some loss of information. In 
addition, the data abstraction that follows the stack abstraction is often not 
distributive either (e.g., [20,8]), which may increase the gain in precision. 

Moreover, backward analysis can be easily defined with a stack abstraction. 
Backward analysis is especially useful when combined with forward analysis, 
when one is interested in the set of states reachable from some initial states 
and leading possibly to some final states, as for the debugging problem of the 
introduction or test selection. In this case, forward analysis from the initial 
states returns a set reach of reachable states. Then we perform a backward 
analysis from the final states intersected with reach ; practically, pre? (Y) is 
replaced by pre^(Y) n reach in the definition of G^[Yq\. The intersection during 
the fixpoint iteration allows a more accurate analysis, as the transfer functions 
are not distributive. This scheme can be iterated, each hxpoint computation 
being performed on a restricted state space. Such a scheme has been successfully 
applied to the verification of reactive systems [15], and we are interested in 
extending it to recursive programs. 



4 Subsuming Functional and Call-String Approaches 

Refined Stack Abstraction. In this section we combine the previous abstrac- 
tion A? with the call-string approach. We replace activation records (c n , e„) used 
in At by objects of the form (co . . . c n , e n ), called extended activation records. 
This corresponds to replacing single control points c„ labelling environments by 
sequences Co ... c n , called call strings in [28]. The abstract semantics proposed 
in this section can be seen as a synthesis of the two distinct methods described 
in [28]. 
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Let us note EAct = Ctrl + x LEnv the set of extended activation records. We 
extend the notion of valid calling activation record (see Definition 1) to extended 
activation records, (oj, e) is valid for (u/,e / ) if lu = ujo-c, lo' =u>q-c-c! , and (c, e) is 
valid for (c! , e'). This additional condition increases the precision of the analysis. 

We extend the domain A* defined in Section 3.1, (1) by replacing activation 
records by extended activation records, yielding the abstract domain: 



A s d = p(EAct) x p(EAct) 



( 5 ) 



A s is connected to p(State) by the Galois connection p(State) 
where abstraction a s and concretisation 7 s are defined by: 



A', 



X 



U 



qex 



or 



(M) 



{(co, Co). • -(c ni )} 1 — ► < { (co - - - )} , {(c 0 . . . Cj, e,} I 0<i<n} ) 



7 s : Y = (Y hd ,Y tl ) 



f (co? ^0) • • • (pn 5 ^n) 

V / 


(co . . . Cnj Cn) G 1 hd 


VO <i<n: (c 0 . . . c*, a) G Y t i > 


l - 


q is a consistent stack J 



A s loses less information than A? : thanks to call-strings, we cannot have any 
more the problem of (2). However we have a subtler phenomenon: if (co, eo) is a 
valid calling activation record for (ci, e[) and ei ^ e[ we might have 

(c 0 ,e 0 )-(ci,ei) G 7 s oo:^{(co,eo)-(ci,ei), (c 0 , e' 0 ) ■ (ci, ei)}) (6) 

Hence, while the abstraction keeps the stack length exact, it can still induce 
some “cross-over” of activation records belonging to different concrete stacks. 



Forward Analysis. The transfer function post s , fully defined in [16], is very 
similar to post ‘ ( cf . Tab. 4) but call-strings allow a more accurate “matching” 
of possible calling contexts with top contexts. For instance, 



Post 3 hd (ej 



(ret y:=Pj (x)) 



c)(Y) = 



f 


(w-cal \(c) ■ e, , ej) € Yhd ) 




(w- call(c), e) G Y u 


e (x (fe) ) = £j(fpij fc) ) 1 

e' = e[y (fc) e^fpof 5 )] J 



(7) 



which is to be compared to (3c). 

As in Section 3 and using similar definitions, the forward analysis is not only 
correct but also optimal. Moreover, the second condition of Theorem 2 is no 
longer needed, because we know that an extended activation record can return 
to a caller only when its call-string component is of length at least 2. 

Theorem 3 (Optimality). Let X 0 G p(State) be a set one-element stacks. 
Then we have reach s o a s (Xo) = a s o reach(Xo). This implies that 

reach s hd o a f (X 0 ) = {(c 0 . . . c„, e„) | (c 0 , eo) • • • (c„, e„) G reach(X 0 )} 
reach u o (X 0 ) = {(cq .. .c n ,e n ) \ 3.TG Act + : (co, e 0 ) . . . (c n , e„) -F G reach(Xo)} 
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Discussion. The lattice A s encompasses the two methods proposed in [28]: ab- 
stracted to A? , it corresponds to the functional approach of that paper, whereas 
A s , further abstracted with a data abstraction which does not relate the values 
of input parameters and output parameters, would give the call-string approach. 
As told in the introduction, A s leads to an interprocedural analysis which is both 
control and data context-sensitive. Here we used the call-strings of [28], but this 
could be generalised to the tokens of [18]. Backward analysis can of course be 
defined in the lattice A s similarly as in Section 3. 

5 Data Abstractions 

Our stack abstractions in some way define each an interprocedural analysis 
method, but not an effective analysis, due to infinite data values or unbounded 
size of call strings. We show here which existing abstract lattices are suitable for 
these methods. [16] shows how to extend them with procedure call and return 
operations. We will consider only A s , since A f is a further abstraction of A s . 

We can use the isomorphism A s ~ Ctrl — > ( p(Ctrl * x LEnv )) to associate 
a set of values to each control point (as usual when analysing imperative pro- 
grams). Ctrl being finite, we just need an abstract lattice for p( Ctrl* x LEnv ) in 
order to get an abstract lattice for A s . A natural way to achieve this is to build 
an abstract lattice for p( Ctrl* x LEnv ) by composing abstract domains avail- 
able for p{Ctrl*) and p(LEnv). So we need to abstract p{Ctrl*) and p(LEnv) 
by some lattices Actri a n d Aleuv, as well as a method for combining them. 

Abstractions for call-strings. Several abstract domains are possible for A Ctrl'- 

1. p(Ctrl p ), for some fixed p > 0: the top p elements of stacks are exactly 
represented, the others are completely forgotten, 

2. Reg (Ctrl), the set of regular languages over the finite alphabet Ctrl, together 
with a suitable widening operator, as the one suggested by [13] or 

3. some subsets of regular languages: simple regular languages, star-free regular 
languages, etc., with widening operators if necessary. 

Notice that apart the first one, these abstractions for call strings are more general 
than the one suggested in [28], where only finite partitioning of p{Ctrl*) is 
considered. Here we do not restrict abstract lattices for p(Ctrl*) neither to finite 
lattices nor to finite-height lattices, thanks to the use of widening. 

Abstractions for environments. Any abstract lattice A^Env available for intrapro- 
cedural analysis can be chosen here [8,20, 10,27, 17]. However it shoidd be rela- 
tional in order to be effectively able to represent relations between input and 
output parameters at the exit point of procedures. In particular equality con- 
straints should be possible in Aleuv for implementing an accurate procedure 
return operation. The typical counter-example is the lattice of intervals for nu- 
merical variables, where no relationships between variables can be represented, 
only a conjunction of invariants for each variable. 
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Combining the two abstract lattices. To avoid the inherent difficulties of the 
design of an abstraction combining different data-types (in our case Ctrl* and 
LEnv ), we suggest to combine the lattices abstracting each datatype. We could 
use the tensor product Actri ® Aleuv [21]. However, this product is not finitely 
representable as soon as either Actri or Aleuv is infinite. Instead, we suggest 
the simple solution of [15], which is to take the Cartesian product A = Actri x 
Aleuv In this lattice, relationships between call strings and data values cannot 
be directly represented: an abstract value is just the conjunction of an invariant 
on call strings and an invariant on data values. However, partitioning on A can be 
used to establish relationships between the two components. This technique has 
been used for obtaining relational invariants on Boolean and numerical variables 
in [15], and can be considered as a particular instance of the disjunctive or down- 
set completion method discussed in [7], where the size of disjuncts is bounded by 
the size of the partition. For instance, if we partition Actri x Aleuv according to 
the k last control points in call-strings, we get a lattice isomorphic to Ctrl k — » 
A Ctrl X AcEnv 

Example. Fig. 3 gives a program computing MacCartlry’s 91-function and the 
analysis results, with as initial states (s,n £ Z). The exact denotational seman- 
tics of this function is A n.(if n > 101 then n— 10 else 91). We use the lattice 
A=(Ctrl U Ctrl 2 )— >(Reg( Ctrl) x Pol(Z))^ i.e. we partition A w.r.t. the two top 
control points in the call-strings, and we use convex polylredra for numerical vari- 
ables. As widening operator on Reg(Ctrl) , we use the bisimulation on automata 
of order <5, as in [13], with <5 = 1. Starting analysis with a one-element stack, 
we have Y t i = Yhd for all call-sites and Y f j = 0 elsewhere. Thus Fig. 3 shows only 
Yhd- Observe that the result at point e is both control and data context-sensitive: 
the partitioning on call-strings induces a differentiation of the possible values of 
the input n. We do not find the exact result at point e, because of the convex 
hull on polylredra performed on the results at points ci and c 5 , which are exact. 
In particular, although the result at point c 5 depends on the approximate result 
at point e, it is exact thanks to the context-sensitiveness of the analysis. Clearly, 
partitioning A w.r.t. only the top control point would have lead to much less 
precise information, because of the more frequent use of convex hull. 



6 Related Work 

As explained in the introduction, one can distinguish two main approaches to 
interprocedural static analysis, namely the functional and the operational. The 
functional approach of [6] has been used for instance to analyse the access to 
arrays in interprocedural Fortran programs [9], using the abstract domain of 
convex polylredra [8]. [22] can be seen as an algorithmical implementation of [19] 
using graph reachability techniques, which can be used with finite lattices and 
distributive data flow functions. This technique can be applied to all bit-vector 
analyses and the Bebop tool [1] is based on it. An extension [26] allows to tackle 
some finite-height infinite lattices, like (linear) constant propagation. 
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proc MC(n: int) : (r: int) is 
tl, t2: int; 

begin s: { (s, ?) , (u>C3S, n< 111), (o;c4S, 91 <n< 101)} 
if n > 100 then co:{(co, n>101), (u;c3Co, 101<n<lll), (u;c4Co, n=101)} 
r := n - 10 ci:{(ci, r — n— 10 > 91) , (CJC3C1, 101 <n< 111 A r = n— 10), (o;c4Ci, r = n— 10 — 91) } 
else C2 : { (C2 + CJC3C2, n< 100)} , (CJC4C2, 91<n<100)} 
tl := n + 11; C3 : { (03 +u>C3C3, n < 100 A tl =n+ 11) , {UJC4C3, 91 < n< 100 A tl =n+ 11) } 

, = . , f (c 4 + o;c3C4, n<100 A tl=n+ll A 91<t2< 101 A t2>n+l), 1 

tz : MCCtlJ; c 4 : i ^ C4C4 91 < n < 10 0 A tl=n+ll A 91 <t2< 101 A t2>n+l) J 

. J (C5+UC3C5, n< 100 A tl = n+ll A 91<t2< 101 A t2>n + l A r = 91), 1 

r . M0Ct2J ; C5 . ^ ^ WC4C5; 9i < n < iOO A tl = n+ 11 A 91 < t2 < 101 A t2 > n+1 A r = 9i) J 

end if 

end MC e:{(e, r>91), (wc 3 e, n < 111 A 91 < r < 101 A r > n- 10) , (uqe, 91 < n < 101 A r = 91) } 



Fig. 3. MacCarthy’s 91-function (where u> = (03 4- C 4 )*) 



In the operational approach, [3] considers more complex Pascal programs 
with reference parameter passing, which introduces aliasing on the stack (i.e. 
several variables may refer to the same location in the stack), and nested pro- 
cedure definitions. Unsurprisingly, the devised solution is quite complex. It has 
been implemented using the interval domain for integers [5] . Stacks are collapsed 
more severely than in our model. The proposal of [11], implemented in Moped 
[12] and applied to concurrent programs in [2], relies on the result that the set 
of reachable stacks of a pushdown automata is a regular language, that can be 
represented by finite-state automata. The analysed program is converted to a 
pushdown automaton, and is thus restricted to programs manipulating finite- 
state variables/properties, or requires the finite abstraction of data/properties 
prior the analysis. A recent extension allows the use of some infinite finite-height 
lattices [23] and represents a very interesting mix of the two approaches: push- 
down automata are here extended by associating transformers to transition rules. 
This allows to encode the control part of the program and properties belonging 
to a finite lattice in the pushdown automata, whereas properties belonging to 
a finite-height lattice can be handled by the transformers attached to the tran- 
sitions. Finally, [24] directly represents the stack as a linked list of activation 
records, using the shape analysis of [27]. 

7 Conclusion 

In this paper, we presented an approach to the verification of imperative pro- 
grams with recursive procedures and variables over possibly infinite domains. 
We showed that by relying solely on the principles of abstract interpretation, 
one can derive from the standard semantics of a program an interprocedural 
analysis method. This is done by abstracting in a proper way sets of call-stacks 
of the programs. Such an interprocedural analysis method can then be imple- 
mented after a second data abstraction. We defined two stack abstractions, the 
optimality of which suggests that they are good starting points for the follow- 
ing data abstraction. The first one is equivalent to the functional approach, but 
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offers in addition the specialisation of predicate transformers and clarifies the 
intersection between forward and backward analysis. 

The second stack abstraction, which is both data and control context sen- 
sitive, integrates the two approaches distinguished in [28]. It allows to specify 
complex constraints on the stack yielding an analysis which contains strictly 
more information. This is particularly useful for starting an analysis from initial 
or final states with a non-empty call-stack and also makes the combination of 
forward and backward analysis more efficient, as more information can be used 
for intersecting the two analyses. 

It could be argued that our assumptions on the analysed programs are too 
restrictive. Non-local jumps could be easily added, as in [18], although this would 
suppress our current optimality results. Allowing reference parameter passing 
and handling aliasing on the stack would be very useful to tackle C programs. 
However, it should be noted that all the general approaches, with the notable 
exception of [3], assume like ourselves that intraprocedural instructions modify 
only the top activation record in the stack. Thus they cannot tackle directly 
reference parameter passing. The simplest way for adding this feature in our 
case would be to add aliasing information in activation records and to use it to 
properly update variables passed by reference upon procedure returns. 

An implementation of our analysis is under work, targeted to programs with 
enumerated or numeric variables, following the implementation guidelines de- 
scribed in [16]. The next step would be its application to programs manipulating 
pointers to dynamically allocated objects, using abstract domains such as the 
one of [27]. 
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Abstract. We study the semantics and refinement of mobile objects, considering 
an extension of core UML state machines by primitives that designate the location 
of objects and their moves within a network. Our contribution is twofold: first, we 
formalize the semantics of state machines in MTLA, an extension of Lamport’s 
Temporal Logic of Actions with spatial modalities. Second, we study refinement 
concepts for state machines that are semantically justified in MTLA. 



1 Introduction 

Software development for mobile computing and mobile computations requires appro- 
priate extensions of the traditional methods and concepts for more traditional system 
models. Moreover, the correctness and security of implementations of systems based 
on mobile code presents a major concern, as mobile agents may roam the network and 
must be guaranteed to work reliably in different locations and in different environments. 

In this paper, we attempt to combine semi-formal modeling techniques for mobile 
systems with formal semantics and refinement. For modeling, we consider an extension 
of state machines in the “Unified Modeling Language” (UML [14]) for mobility. We 
first formalize the semantics of mobile state machines in MTLA [11], an extension of 
Lamport’s Temporal Logic of Actions [9] with spatial modalities. Building on this log- 
ical semantics, we study refinement concepts for mobile state machines. In particular, 
we consider two notions of spatial refinement: the first one provides for an object to 
be split into a hierarchy of cooperating objects. The second one can be used to justify 
implementations of some high-level object by a set of objects that need not reside at the 
same location. 

There has been much interest in formalizing concepts of UML as well as in seman- 
tic foundations for mobile computations, and we mention only the most closely related 
work. DeiB [6] suggested an encoding of (Harel) Statecharts in TLA, without consid- 
ering either mobility or refinement. Several formal models of mobile computation have 
been proposed, either in the form of calculi as in [5, 12] or of state machine models 
as in [8], and sometimes accompanied by logics to describe system behavior [4, 13], 
but we are not aware of refinement notions for mobile computation. Our definitions of 
refinement of state machines are partly inspired by [15, 16]; a related notion has been 
elaborated in [17]. 

C. Rattray et al. (Eds.): AMAST 2004. LNCS 3116, pp. 274-288, 2004. 

© Springer- Verlag Berlin Heidelberg 2004 
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Fig. 1. Prefix of a run. 



1.1 Mobile UML 

Mobile UML [2,3, 10] extends UML [14] by concepts for modeling mobile compu- 
tation. The extension is described in terms of the UML itself, using stereotypes and 
tagged values as meta-modeling tools. Most importantly, instances of classes distin- 
guished by the stereotype <docation» denote locations where other objects may reside. 
Mobile objects are instances of classes with the stereotype - mobile^ and may change 
their locations over life-time. An actual movement of a mobile object is performed by 
a move action that takes the target location as its parameter. 



1.2 MTLA 

The logic MTLA [11] is an extension of Lamport’s Temporal Logic of Actions [9] 
intended for the specification of systems that rely on mobility of code. Due to space 
restrictions, we refer to [1 1] for precise definitions of its syntax and semantics and only 
recall the basic intuitions and notations. 

Following the intuition of the Ambient calculus [5] due to Cardelli and Gordon, 
we represent a configuration of a mobile system as a finite tree of nested locations. 
In this view, mobility is reflected by modifications of the location hierarchy, as agents 
move in and out of nested domains. Unlike in the Ambient calculus, we assume that 
locations carry unique (“physical”) names. Moreover, instead of endowing each node 
of a configuration tree with a process, MTLA associates a local state with every node. A 
run is modeled as an co-sequence of configuration trees. For example, Fig. 1 shows three 
configurations of a system run. The transition from the first to the second configuration 
models a local action that changes the value of the local attribute ctl associated with 
location ag. The second transition represents a move of ag from the location no to the 
location n\ . 

The logic MTLA contains both temporal and spatial modalities. Its formulas are 
evaluated over runs, at a given location. Temporal modalities refer to the truth value of 
formulas at suffixes of a run. For example □ F asserts that F holds of all suffixes of the 
run, at the current location. 

Similarly, spatial modalities shift the spatial focus of evaluation, referring to loca- 
tions below the current one. For example, the formula m[F] asserts that F is true of the 
current run when evaluated at location m, provided such a location occurs (strictly and 
at arbitrary depth) below the current location, otherwise m[F] is trivially satisfied. The 
dual formula m(F) asserts that the location m occurs beneath the current location, and 
that F holds there. For example, the run of Fig. 1 satisfies the formula ag[ctl = Idle] 
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at the root location. We frequently use a more convenient dot notation to refer to local 
attributes at a given location and write, e.g., ag.ctl = Idle. 

As in TLA, we use formulas to describe systems as well as their properties. State 
transitions are specified using transition formulas that contain primed symbols, as in 
ag.ctl = Idle A ag.ctl' = Shopping. When P is a state formula (i.e., without primed 
symbols), we write P' for the transition formula obtained by replacing all flexible sym- 
bols by their primed counterparts; intuitively, this formula asserts that P holds of the 
successor state. MTLA adds a transition formula a.n 7A [3 . a where n is a name and 
a and (3 are sequences of names. This formula asserts that the subtree rooted at name 
n within the tree indicated by a moves below the path (3. The next-state relation of a 
system is specified by the temporal formula □ [A] v asserting that every transition that 
modifies the expression v must satisfy the action formula A. Similarly, n[A] a .„, where 
n is a name and a is a sequence of names stipulates that every transition that removes 
or introduces location n below the subtree indicated by a must satisfy A. 

Hiding of state components can be expressed in MTLA using existential quantifi- 
cation. For example, 3 ag.ctl : F holds if one can assign some value to the attribute 
ctl of location ag at every state such that F holds of the resulting run. As in TLA, the 
precise definition is somewhat more complicated in order to preserve invariance under 
stuttering. One may also quantify over names and write 3 n : F; this hides the name as 
well as all its attributes. These quantifiers observe standard proof rules. In particular, 
we have the introduction axioms 

(3 -ref) F{t /n,ti/n.ai, . . . ,tk/n.ak} =>3n : F 
(3-sub) m(true) => 3 n : m.n(true) (m ^ n) 

The axiom ( 3 -ref) asserts that 3 n : F can be derived by finding a “spatial refine- 
ment mapping” that substitutes witnesses for the hidden name n as well as for its at- 
tributes. The axiom (3 -sub) allows us to introduce a new sublocation n of an existing 
location m. 



2 Statecharts and Their MTLA Semantics 

We introduce state machines for mobile objects and provide them with a formal seman- 
tics based on MTLA. Our concepts are illustrated by means of the “shopper” example: 
A mobile shopping agent is sent out to gather offers for some item in several shops; 
when returning to its home base, the shopping agent presents the offers that it has found. 

2.1 State Machines for Mobility 

UML state machines, an object-oriented variant of Statecharts as defined by Harel [7], 
are an expressive and feature-rich class of state transition systems with a complex se- 
mantics [18]. In this paper, we consider a restricted class of state machines, but extended 
by a special move action. In particular, we consider neither hierarchical nor pseudo- 
states, with the exception of a single initial state per state machine. We consider only 
events triggered by asynchronous signals (excluding call, time, and change events) and 
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« location” Site 



name : String 
present(offers : List) 



«mobile» Shopper 

name : String 
home : Site 

look(i : Item) 
offer(o : Offer) 



[@home] 



look(item) / 
(lookFor, offers) 
= (item, {}) 




[@home] / 
home.present(offers) 



offer(o) / 

offers=add(offers,o) 



/ ANY I : Site : 
move(l) 



(a) Class diagram. (b) State machine for the shopper. 

Fig. 2. High-level model for the shopper. 



ignore deferred events. Although our encoding could be extended to encompass all fea- 
tures of UML state machines, the simplifications we impose let us concentrate on the 
problems of mobility and refinement that are our primary concern. 

Transitions of state machines carry labels of the form trig[grd\/ act, any and all of 
which can be absent. The trigger trig denotes a signal receptions of the form op (par) 
where op is the name of an operation declared in the class and par is a list of parameters. 
The guard grd is a Boolean expression over the attributes of the class and the parameters 
that appear in the trigger clause. In addition, we allow for guards e\ -< e 2 that refer to 
the hierarchy of objects; such a clause is true if (the object denoted by) e\ is currently 
located beneath e 2 . The most common form is self -< e, requiring the current object to 
be located below e, which we abbreviate to @e. The action act denotes the response 
of an object, beyond the state transition. For simplicity, we assume that all actions are 
of the form ANY x : P : upd', send', move where each of the constituents may be absent. 
Herein, P is a predicate over location objects, and ANY x : P functions as a binder 
that chooses some location object x satisfying P which can be used in the remainder 
of the action. The upd part is a simultaneous assignment (cq , . . . , a&) = (e \ , . . . , e*) of 
expressions e. ( to attributes <q. The send part is of the form e.op (par) and denotes the 
emission of a signal op with parameters par to receiver object e. Finally, the move part 
consists of a single move(e) action that indicates that the object should move to the 
location object whose identity is denoted by e. We require that all free variables in the 
action are among the attributes of the class, the parameters introduced by the trigger, and 
the location x bound by ANY. Figure 2(b) shows a first state machine for our shopping 
agent, based on the class diagram of Fig. 2(a). For the subsequent refinements, we will 
not explicitly indicate the class diagrams, as they can be inferred from the elements that 
appear in the state machines. 

Our interpretation of transitions deviates in certain ways from the UML standard. 
First, the UML standard prioritizes triggerless transitions (so-called “completion transi- 
tions”) over transitions that require an explicit triggering event. In contrast, we consider 
that completion transitions may be delayed; this less deterministic interpretation is more 
appropriate for descriptions at higher levels of abstraction. As a second, minor devia- 
tion, we allow guards to appear in transitions leaving a state machine’s initial state. 



278 



Alexander Knapp, Stephan Merz, and Martin Wirsing 



2.2 MTLA Semantics of State Machines 

We formalize systems of interacting, mobile state machines in MTLA. The formaliza- 
tion enables us to prove properties about systems specified in UML. We will also use it 
to justify correctness-preserving refinement transformations. 

In MTLA, every object is represented by a MTLA location whose local state in- 
cludes a unique, unmodifiable identifier self. We denote by Obj the set of all MTLA 
locations that represent objects of a given object system. The subset Loc denotes the 
set of MTLA locations that represent UML Location objects (including Mobile Loca- 
tions), and the formalization of a system of state machines at a given level of abstraction 
is with respect to these sets Obj and Loc. An object configuration is represented as a 
tree of names as described in Sect. 1.2. 

The local state at each node represents the attributes of the corresponding object, 
including self. In addition, we use the attributes ctl to hold the current control state of 
the object (i.e., the active state of the corresponding state machine) and evts to repre- 
sent the list of events that are waiting to be processed by the object. Objects interact 
asynchronously by sending and receiving messages. In the MTLA formalization, the 
communication network is represented explicitly by an attribute msgs located at the 
root node of the configuration tree. 

Every transition of an object is translated into an MTLA action formula that takes a 
parameter o denoting the location corresponding to the object. For lack of space, we do 
not give a precise, inductive definition of the translation, but only indicate its general 
form. In the following, if tp is an MTLA expression (a term or a formula), we write 
cp x and cp 0 , respectively, for the expressions obtained by replacing x by x.self and by 
replacing all attributes a of o by o. a. 

The action formula representing a transition is a conjunction built from the transla- 
tions of its trigger, guard, and action components. The automaton transition from states 
src to dest is reflected by a conjunct o.ctl = src A o.ctl' = dest. 

A trigger op (par) contributes to the definition of the action formula in two ways: 
first, the parameters par are added to the formal parameters of the action definition. 
Second, we add the conjunct 

-> empty (o. evts) A head^o .evts) = (op, par) A o.evts' = tail(o.evts) 

asserting that the transition can only be taken if the trigger is actually present in the 
event queue and that it is removed from the queue upon execution of the transition. 
For transitions without an explicit trigger we add the conjunct UNCHANGED o.evts to 
indicate that the event queue is unmodified. 

A Boolean guard g over the object’s attributes is represented by a formula g 0 , in- 
dicating that g is true at location o. A constraint e\ -< e 2 on the hierarchy of objects is 
represented by a conjunct of the form 

V oi. self = (ei ) 0 A 02 -self = (e 2 ) 0 A o 2 .oi (true) 

°l:°2 ^Obj 

The representation of an action consists of action formulae for multiple assignment, 
message sending, and moving. If an action shows an ANY x : P quantifier the conjunc- 
tion acts of these formulae are bound by a disjunction Vxez,oc P x A acts x . In more 
detail, a multiple assignment to attributes is represented by a formula 
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o.a[ = (ei)* A . . . A o.a' k = (ek) x 0 A UNCHANGED (o.Ofc+i, . . . , o.a n ) 

where a,k+ 1 are the attributes of o that are not modified by the assignment and 

where x is the variable bound by ANY. Sending a message e.op (par) is modeled by 
adding a tuple of the form (e® , op, par*) to the network msgs. For actions that do not 
send a message we add the conjunct msgs' = msgs. If the action contains a clause 
move(e), we add a conjunct 

\J l.self = e* Ae.o l.o 

IGLoc 

that asserts that o will move to (the location with identity) e Q . Otherwise we add the 
conjunct AzeLoc[f a l se ko, which abbreviates /\ leLoc (l.o(true) «=> OLo(true)), to indi- 
cate that the object does not enter or leave any location in Loc. 

To model the reception of new events by the object, we add an action RcvEvt(o , e) 
that removes an event e addressed to o from the network and appends it to the queue 
evts of unprocessed events while leaving all other attributes unchanged. We also add an 
action DiscEvt(o) that discards events that do not have associated transitions from the 
current control state. The entire next-state relation Next(o) of object o is represented as 
a disjunction of all actions defined from the transitions and the implicit actions RcvEvt 
and DiscEvt, existentially quantifying over all parameters that have been introduced in 
the translation. 

A state predicate Init(o) defining the initial conditions of object o is similarly ob- 
tained from the transition from the initial state of the state machine. Finally, the overall 
specification of the behavior of an object o of class C is given by the MTLA formulas 

IC(o) = A Init(o) A o.evts = () A U[Next(o)] attr ^ 0 ) A □ [false] 0 . sei / (1) 

A /\ieLoc a [ N ext{°)\i. 0 

C(o) =3o. ctl, o. evts : IC(o) (2) 

The “internal” specification IC(o) asserts that the initial state must satisfy the ini- 
tial condition, that all modifications of attributes of o and all moves of o (entering or 
leaving any location of Loc ) are accounted for by the next-state relation, and that the 
object identity is immutable. Here, attr(o) denotes the tuple consisting of the explic- 
itly declared attributes and the implicit attributes ctl and evts. For example, the formula 
IShopper(ag) shown in Fig. 3 defines the behavior of an object ag of class Shopper 
introduced in Fig. 2(b). The “external” specification C(o) is obtained from IC(o) by 
hiding the implicit attributes ctl and evts . 

The specification of a finite system of objects consists of the conjunction of the 
specifications of the individual objects. Moreover, we add conjuncts that describe the 
hierarchy of locations and objects and that constrain the network. For our shopper exam- 
ple, we might assume a typical system configuration being given by the object diagram 
in Fig. 4. This configuration can be translated into the formula 

Sys = 3 msgs : A Ak=i shi(self = shop-i A joe [false] A AjLishj [false]) A Site(shi) 
A joe(self = joe A A £Li sK [false]) A Site(joe) 

A joe.ag(self = shopper) A Shopper(ag) 

^ /\l£Loc ^ [f a l s c] l.shj ,...,l.sh}f,l.joe 

A msgs = () A □ [ \J oe0 b 3 Next(o)\ msgs 
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Init(ag) 
Stationary (ag) 
Deq(ag,msg) 
Look(ag , item) 



Offer(ag,o) 



Present(ag) 



Move(ag) 



RcvEvt(ag , e) 



DiscEvt(ag) 



Next(ag) 

attr(ag) 

IShopper(ag) 



ag.ctl = Idle A \/ i sLoc (l.ag (true) A ag.home = l.self) 

f \lGLOC [ltd SO £ a g 

-i empty (ag. evts) A head (ag.evts) = msg A ag.evts' = tail(ag.evts) 

A ag.ctl = Idle A ag.ctl' = Shopping A Deq(ag, (look, item)) 

A ag.lookFor' = item A ag .offers' = {} A UNCHANGED ag.home 
A msgs' = msgs A Stationary (ag) 

A ag.ctl = Shopping A ag.ctl 1 = Shopping A Deq(ag, (offer, o)) 

A ag. offers' = add(ag. offers, o) A UNCHANGED (ag.lookFor , ag.home) 
A msgs' = msgs A Stationary (ag) 

A V leObj ag.home = l.self A Lag (true) 

A ag.ctl = Shopping A ag.ctl 1 = Idle 

A UNCHANGED (ag.lookFor, ag. offers, ag.home, ag.evts) 

A msgs' = msgs U {(ag.home, present, ag. offers)} 

A Stationary (ag) 

\/i£Loc A Lsel f £ Site 

A ag.ctl = Shopping A ag.ctl' = Shopping 
A unchanged (ag.lookFor, ag. offers, ag.home, ag.evts) 

A msgs' = msgs Ae. ag 2> l.ag 
A (ag.self ,e) e msgs Amsgs' = msgs \(ag. self ,e) 

A ag.evts' = append (ag. evts, e) 

A UNCHANGED { ag.ctl , ag.lookFor, ag. offers, ag.home) 

A Stationary (ag) 

A -> empty (ag.evts) A ag.evts' = tail(ag.evts) 

A -i 3 % : head(ag.evts) = (look, i) V ag.ctl Idle 
A -do : head(ag.evts) = (offer, o) V ag.ctl Shopping 
A UNCHANGED (ag.ctl, ag.lookFor, ag. offers, ag.home) 

A msgs' = msgs A Stationary (ag) 

V (3i : Look(ag,i))W (3o : Offer(ag,o))V Present(ag) 

V Move(ag) V (3e : RcvEvt(ag, e)) V DiscEvt(ag) 

( ag.ctl , ag.lookFor, ag. offers, ag.home, ag.evts) 

A Init(ag) A ag.evts = () Aa[Next(ag)\ attr ( ag) A □ [false] Q5 . sei/ 

A A leLoc a l Next ( a g)] Lag 



Fig. 3. MTLA specification of the shopper behavior (see Fig. 2(b)). 



«location» joe : Site 




« location » 
ag : Shopper 







«location» sh7 : Site 



“location” sh N : Site 



Fig. 4. Object diagram for the shopper example. 



The formula in the scope of the existential quantifier asserts that the configuration 
contains the N + 1 sites sh\,... , sh,N and joe, and a shopping agent ag. Moreover, joe 
and the shops are immobile and unnested locations, whereas ag is situated beneath 
joe. The last conjunct asserts that messages are only sent and received according to 
the specifications of the participating objects. The external specification is obtained by 
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1 Shopping 




Fig. 5. Refined state machine for the shopper. 



hiding, via existential quantification, the set of messages in transit, which is implicit at 
the UML level. 

For this example, Obj is the set {sh\,...,sh,N,joe,ag} and Loc = Obj \ {ag}. 
Moreover, we define a set Site containing the identities of the elements of Loc, i.e. 
Site = {shop-1, . . . ,shop-iV,joe}. 

One purpose of our formalization is to prove properties about a system of objects. 
For the shopper example, we can deduce that the shopping agent is always located at its 
home agent or at one of the shops, expressed by the formula 

V ^- a 5( true )) (3) 

' leLoc ' 



3 Refinement of State Machines 

In an approach based on refinement, interesting correctness properties of systems can 
already be established for models expressed at a high level of abstraction. Subsequent 
models introduce more detail, but ensure that all properties are preserved. In this paper, 
we focus on the refinement of state machines, and we add a “spatial” dimension to re- 
finement that allows a designer to introduce more structure in the object hierarchy. In 
particular, a single high-level object can be refined into a tree of sub-objects. Through- 
out, we assume that the public interface of a refining class contains that of the refined 
one, and that the sets Obj and Loc of objects and Location objects of the refining model 
are supersets of those of the refined model. 

3.1 Interface Preserving Refinement 

Usually, early system models afford a high degree of non-determinism, which is re- 
duced during system design. For example, consider the state machine for the shopping 
agent shown in Fig. 5, which imposes a number of constraints with respect to the state 
machine shown in Fig. 2(b). After arriving at a new shop location (whose identity is 
recorded in the additional attribute loc), the agent may now either query for offers by 
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sending a new message getOffer or it may immediately move on to another neighbor 
location. In the former case, the agent waits until the offers are received, adds them to 
its local memory, and then moves on. When the agent arrives at its home location, it 
may quit the cycle, presenting the collected offers and returning to the Idle state. 

Intuitively, the state machine of Fig. 5 is a refinement of the one shown in Fig. 2(b) 
because the states of the refined state machine can be mapped to those of the high-level 
state machine such that every transition of the lower-level machine either is explicitly 
allowed or is invisible at the higher level. In particular, the states Ready, Arrived. Wait- 
Offer, and Returning can all be mapped to the high-level state Shopping, as indicated by 
the dashed line enclosing these states. Assuming that the set nbs(s) contains only iden- 
tities in Site, for all s £ Site, each transition of the refined model either corresponds to 
a transition of the abstract model or to a stuttering transition. For example, the transition 
from Arrived to WaitOffer is invisible at the level of abstraction of the model shown in 

Fig. 2(b). 

We now formalize this intuition by defining the notion of a state machine R refin- 
ing another state machine M for a class C. Semantically, refinement is represented in 
linear-time formalisms by trace inclusion or, logically, by validity of implication. How- 
ever, we will be a little more precise about the context in which M and R are supposed 
to be embedded. Both machines are specified with respect to attribute and method sig- 
natures X fi and X A/ that include all method names that appear in transition labels (either 
received or sent), and we assume that 1, R extends X A 1 . Similarly, we assume that the 
sets Obj R and Loc R of MTLA names for the objects and the Location objects at the 
level of the refinement are supersets of the corresponding sets Obj M and Loc M at the 
abstract level. Finally, the refinement may be subject to global hypotheses about the 
refined system, such as the hierarchy of names, that are formally asserted by an MTLA 
state predicate H . Thus, we say that the class It with associated state machine formal- 
ized by the MTLA formula C R refines class M whose state machine is described by 
C M under hypothesis H if for all system specifications Sys M and Sys R where Sys R 
results from Sys M by replacing all occurrences of C M (o) by C R (o ) and by conjoining 
some formulas such that Sys R implies OH, the implication Sys R => Sys M is valid. 

In order to prove that R refines M, we relate the machines by a mapping T| that 
associates with every state s of R a pairr|(s) = (Inv(s),Abs(s)) where Inv(s) is a set 
of MTLA state predicates, possibly containing spatial operators, and where Abs(s) is a 
state of M . With such a mapping we associate certain proof obligations: the invariants 
must be inductive for R, and the (MTLA formalizations of the) transitions of the ma- 
chine R must imply some transition allowed at the corresponding state of M, or leave 
unchanged the state of M . 

Theorem 1. Assume that M and R are two state machines for classes C M and C R 
such that the attribute and method signature 1, R of C R extends the signature X A/ of 
C M , and that r| is a mapping associating with every state s of R a set Inv(s) o/MTLA 
state predicates and a state Abs(s) of M. If all of the following conditions hold then R 
refines M under hypothesis H. We write ty for 

q>{Abs(o.ctl)/ o.ctfo.evts]^ / o.evtSjmsgs^^M /msgs} 
where ejx denotes the subsequence of elements e whose first component is in X. 
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refuse() 




Fig. 6. Spatial refinement of the network sites. 



1. Abs{s R ) = Sq 1 where Sq 4 and s R denote the initial states of M and R. Moreover, 

\= H A Init R (o) => o[Inv(s R )] A Init M (o ) 

holds for the initial conditions Init R and Init M of M and R. 

2. For every transition of R with source and target states s and t formalized by the 
MTLA action formula A(o,par): 

\= H A H' A o[Inv(s)} A A(o,par) => o[Inv(t)'} 

3. For every state s of R and every outgoing transition of s formalized by formula 
A(o,par), let A&s(s) denote the corresponding state of M, let B\(o,par\), 
B m (o,par m ) be the MTLA formulas for the outgoing transitions of Abs(s), let 
attr M (o) be the tuple of attributes defined for M and Loc M the set of locations 
for M . Then: 

|= H A H' A o[/7w(s)] A A(o,par) => 

V V™i(3paA : Bi(o,pa ri)) 

V UNCHANGED {attr M (o) ^msgs]^) /\ /\i eLoCM fiaAse\i. 0 

Theorem 1 ensures that R can replace M, subject to hypotheses FT. In particular, all 
properties expressed by MTLA formulas that have been established for the high-level 
system will be preserved by the implementation. 

In order to prove that the state machine of Fig. 5 refines that of Fig. 2(b) (with re- 
spect to H = Vs £ Site : nbs(s) £ Site ) we must define the mapping T|. We have already 
indicated the definition of the state abstraction mapping Abs. For the mapping Inv , we 
associate (the MTLA encoding of) @home with state Returning and ag.loc £ Site with 
all other states. It is then easy to verify the conditions of Theorem 1. In particular, the 
transitions leaving state Arrived do not modify the shopping agent’s attributes, and they 
do not send messages contained in the original signature. They are therefore allowed by 
condition (3) of Theorem 1 . 

Theorem 1 can also be used to justify refinements that modify the spatial hierarchy 
of locations. Consider the state machine shown in Fig. 6. It is based on the idea that 
prior to interacting with an object, incoming agents are first placed in a special subloca- 
tion for security checking. Instead of a simple, atomic move from one shop to another 
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[@home] / home. present(dt. res) 



offer(o) / 

dt.res=add(dt.res,o) 



[not empty(path.rt)] / 
path.rt = tail(path.rt); 
move(head(path.rt)) 



Fig. 7. Spatial refinement of the shopper. 



as in Figs. 2(b) and 5, this version moves the shopping agent first to the “incoming” 
sublocation of the target location. If the agent is accepted by the host, as modeled by 
the reception of an admit signal, it transfers to the “dock” sublocation where the real 
processing takes place. Otherwise, the host will send a refuse signal, and the shopping 
agent moves on to another neighbor host. Here we assume that every location l £ Loc 
contains sublocations Lin and Ldock. Moreover, we assume functions incoming and 
dock that look up the id’s of the corresponding sub-locations for a given network site. 

Formally, Theorem 1 can again be used to show that the “docked” shopper of Fig. 6 
is a refinement of that shown in Fig. 5 with respect to the hypothesis 

A A L Lin (true) A l. Ldock (true) 
ieLoc M A incoming(Z.seZ/) = Lin. self Adock(Z.seZ/) = Ldock. self 

The states Incoming and Docked are mapped to the single high-level state Arrived, and 
the invariant mapping associates (the MTLA encoding of) @loc with the location In- 
coming and ag.loc £ Site with all states. Indeed, the move action labeling the transition 
from the Ready to the Incoming state will be formalized by an MTLA action formula 
V ieLoc RS ~ a 9 ^ L in.ag, which implies the corresponding formula V ieL OC M e - a 9 ^ 
Lag formalizing the move between the high-level states Ready and Arrived, using the 
hypothesis H. Similarly, H and the invariant establish that the move between the In- 
coming and Docked states maps to a stuttering action: Clearly, the local attributes and 
the message queue are left unchanged. Moreover, the invariant associated with state In- 
coming asserts that the agent is located beneath the site (with identity) loc. Therefore, a 
move to the “dock” sublocation of that same site is invisible with respect to the locations 
in Loc M : the action implies [false] i. ag , for all l £ Loc M . 

For these kinds of refinement to be admissible, it is essential that the spatial oper- 
ators of MTLA refer to locations at an arbitrary depth instead of just the children of 
a node and that it is therefore impossible to specify the precise location of the agent. 
In fact, we consider the concept of “immediate sublocation” to be as dependent on the 
current level of abstraction as the notion of “immediate successor state”, and MTLA 
allows to express neither. 

3.2 Interface Refinement I: Spatial Distribution of State 

Frequently, refinements of the spatial hierarchy will be accompanied by a distribution 
of the high-level attributes over the hierarchy of sublocations of the refined model. For 
a simple example, departing again from the high-level shopper of Fig. 2(b), consider 
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the state machine shown in Fig. 7. Here we assume that the shopping agent contains 
two sub-agents path that determines the path to follow through the network and dt that 
collects the data, and we have replaced the attributes lookFor and offers of the high- 
level shopper by attributes tgt and res assigned to the dt sub-agent 1 . The transition 
from Idle to GotRoute determines the route of the agent. It is guarded by the condition 
r £ Seq(Site), asserting that r is a list of (identities of) network sites. 

Spatial distribution of attributes is similar to the concept of data refinement in stan- 
dard refinement-based formalisms. Intuitively, the refinement of Fig. 7 is admissible 
provided that the public interface is preserved. We will therefore assume that the at- 
tributes item and offers have been marked as private in the class diagram for the abstract 
shopper, ensuring that no other object relies on their presence. 

Formally, we modify slightly the MTLA formalization of state machines, taking 
into account the visibility (either “private” or “public”) of attributes. We redefine the 
external specification of the behavior of an object o of class C with private attributes 
, . . . , Uk as the MTLA formula 

C{o ) = 3 o.ai, . . . , o.dk, o.ctl, o.evts : IC(o) (4) 

where IC(o ) is defined as before by formula (1). Since the specification of an object 
system is based on the external object specification, private attributes are invisible at the 
system level, and the definition of refinement modulo a hypothesis remains as before. 

The verification of refinement relies on conditions generalizing those of Theorem 1, 
provided that the private attributes of the high-level object can be computed from those 
of the implementation via a refinement mapping [1], The relation between the two di- 
agrams R and M is therefore given by the mapping t] as before, complemented by 
terms ti,...,tk that represent the values of the private high-level attributes a\ , a.k. 
These terms have then to be substituted for the attributes in the formulas concerning the 
high-level state machine M . 

Theorem 2. Extending the context of Theorem 1 by terms t\ , . . . , £&, we now write tp for 

<${Abs(o .ctl) / o .ctl , o.evts]-£M / o.evts,msgs]-^M / msgs, t\/ o.a\,. . . ,tk/ o.ak} 

If the set of public attributes of R is a superset of those of M then R refines M under 
hypothesis H up to hiding of attributes o.a \, ... o.ak if the conditions of Theorem 1 hold 
for this new interpretation of substitution. 

For the example shown in Fig. 7, the hypothesis is 

H = ag .path (true) A ag.dt (true) 

The implementation states Idle and GotRoute are both mapped to the abstract state 
Idle. The invariant mapping assigns the state formula ag.path.rt £ Seq(Site) to the 
states GotRoute and Shopping. Finally, the refinement mapping is defined by substi- 
tuting ag.dt. res and ag.dt. tgt for ag. offers and ag. lookFor, respectively. All proof 
obligations of Theorem 2 are then easily verified. 

1 The renaming of the attributes is not necessary, but will make it clear in the following to which 
model we are referring. 



286 



Alexander Knapp, Stephan Merz, and Martin Wirsing 



[@home] l 
loc=home J 

Idle 



look(item) / 

(lookFor,offers)=(item,{}) 



offer(o) / 

offers=add(offers,o) 

move(transit) 



Shopping 




Shipping 



[@home] / 
home.present(offers) 



ANY I : Site : 
loc=l; move(l) 



Fig. 8. State machine for the “slow shopper”. 



3.3 Interface Refinement II: Virtualisation of Locations 

Whereas the notions of spatial refinement that we have considered so far have intro- 
duced new (sub-)objects, we have taken care to preserve the hierarchy of the objects 
present at the abstract levels. Together with the choice of modalities of MTLA, which 
cannot express the precise location of an object, we have thus been able to represent 
refinement as implication and to preserve all MTLA properties. However, it can occa- 
sionally be desirable to allow for refinements that do not at all times preserve the spatial 
relationships imposed by the original specification. 

For example, the previous specifications of the shopping agent have all assumed 
that moves between locations happen atomically. Figure 8 presents a variation of the 
original state machine of Fig. 2(b) where the agent moves to an intermediate transit 
location, which is not included in Site, before moving to the next site. (A subsequent 
refinement could add more structure to the transit location, modeling the transport of 
the agent across the network.) We cannot use Theorems 1 or 2 to prove that this model 
refines the original one because the move to the transit location cannot be mapped to 
any high-level action. In fact, the MTLA formula representing the “slow shopper” does 
not imply the formula encoding the original specification, and the invariant formula (3) 
asserting that the shopping agent is always located at some location that represents a 
network site does not hold of the slow shopper. 

Such relationships can be formalized by considering a weaker notion of refinement, 
abstracting from some of the names that occur in the original specification. In our run- 
ning example, the name of the shopping agent should not actually be part of the inter- 
face: the purpose of the system is that the agent’s home site learns about offers made by 
other network sites; the use of a mobile agent is an implementation detail. We say that an 
object system formalized by an MTLA formula Impl refines another system formalized 
by Spec up to hiding of name n if the implication Impl => 3 n : Spec holds. In general, 
the behavior required of object n at the abstract level may be implemented by several 
implementation objects, hence it does not appear useful to give a “local” rule, similar 
to Theorems 1 and 2, that attempts to prove refinement by considering a single state 
machine at a time. Instead, the strategy in proving such a refinement is to define a “spa- 
tial refinement mapping”, using the rules given in Sect. 1.2. For the slow shopper, we 
first use rule (3 -sub) to introduce a new sublocation, say l_virtual, for every high-level 
location l and then define a refinement mapping that returns the implementation-level 
agent as long as it is not at the transit location, and otherwise the location l_virtual as- 
sociated with the previous site visited as stored in the attribute loc. The local attributes 
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of the high-level shopper are simply obtained from those of the implementation-level 
agent. Observe in particular that the invariant (3) cannot be proven of the specification 

3 ag : Sys because ag is no longer free in that formula. 

Refinement up to hiding of names allows for implementations that differ more rad- 
ically in structure. For example, the single shopping agent of the initial specification 
could be implemented by a number of shopping agents that roam the network in parallel, 
cooperating to establish the shopping list. On the other hand, a correct implementation 
could also be based on a client-server solution instead of using mobile agents. 

4 Conclusion 

We have studied the applicability of the logic MTLA proposed in [11] in view of for- 
malizing Mobile UML State Machines [3] and of establishing refinement relationships 
between models described in this language. A configuration of a mobile system is rep- 
resented as a tree of names, and mobility is reflected by changes to the name hierarchy. 
MTLA accomodates local attributes at every node in the tree, simplifying the formal- 
ization of state-based notations such as UML state machines. The operators of MTLA 
have been designed to support system refinement; in particular, all spatial operators re- 
fer to nodes arbitrarily deep beneath the current node and not just its children as in other 
spatial logics, e.g. [4]. 

We have assumed some simplifications and restrictions for our formalization of 
Mobile UML state machines. In particular, we assume that spatial relationships are 
specified using constraints e\ -< e 2 , comparing the relative positions of two objects at 
the current level of abstraction. This assumption has been essential to obtain a sound and 
elegant representation of refinement as implication of specifications for mobile systems. 

Our main objective has been the study of three fundamental refinement principles, 
focusing on refinements of the spatial hierarchy. We have indicated sufficient conditions 
for verifying refinement. However, these conditions are incomplete: in particular, it is 
well known that refinement mappings need to be complemented by devices such as his- 
tory and prophecy variables in order to obtain completeness [1]. We have also ignored 
liveness and fairness properties in this paper, and we have mostly restricted ourselves 
to proving refinement “object by object”. We intend to study adequate composition and 
decomposition concepts in future work. 
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Abstract. In areas like manufacturing, communications, transportation 
or aerospace, the increasing size and complexity of reactive systems make 
their verification difficult to handle. Compositional reasoning is a way to 
master this problem. In this paper, we propose an approach based on a 
constraint synchronized product to specify and to verify such systems. 
This approach supports a compositional refinement for both labelled 
transition systems and their composition. In this framework, we show 
how to verify local and global invariance properties during a refinement 
verification. Thus, these properties are preserved through refinement. 
The different aspects of our work are illustrated on the example of a 
communication protocol between an integrated chip card and a reader 
interface device. 

Keywords: Invariance properties, refinement, compositional verifica- 
tion, synchronized product, preservation. 



1 Introduction 

Invariance properties (also called invariants) are fundamental in specification and 
verification of complex reactive systems. Size and complexity of specification and 
development continue to grow making these systems more and more difficult to 
understand and to handle. 

Compositional reasoning is a way to master this complexity and to postpone 
the state explosion problem while verifying these systems by enumeration. Our 
compositional method describes the system’s components and their interactions 
instead of building the whole system. For that, we define a specific composition 
operator, a kind of constraint synchronized product, that models synchronous 
and asynchronous behaviours. One of its advantages is that this composition 
operator supports a refinement of transition systems. It allows us to master the 
complexity of specifications with a step by step development process. In [13] 
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the refinement of the whole system is linked with the weak refinement of its 
expanded components. In addition, this component-based refinement guarantees 
preservation of the abstract system reachability properties, and the deadlock 
freedom, for the refined ones. It seems natural to answer the question about 
invariants’verification in this framework. 

In this paper, we focus on two invariance properties: local and global in- 
variants. Local invariants relate to the allowed behaviours of one of the system 
components whereas global invariants express the allowed whole system’s be- 
haviours. 

We show that both kinds of 
invariants can be checked compo- 
sitionally when systems are spec- 
ified by the constraint synchro- 
nized product. This verification 
of invariants can be done while 
verifying our compositional refine- 
ment without increasing this al- 
gorithm’s complexity. Moreover 
these invariants are preserved by 
refinement (see Fig. 1). 

This paper is organised as follows. After giving preliminary notions, we de- 
fine, in Section 2, the behavioural semantics of synchronized component-based 
systems. In Section 3, we show how this semantics is well-adapted to composi- 
tional invariance property verification. Then, in Section 4, we recall a refinement 
relation and give a compositional refinement verification method preserving in- 
variance properties. Throughout this paper, our work is illustrated on an indus- 
trial example of a communication protocol between an integrated chip card and 
a reader interface device. We end by a tool presentation and some perspectives. 
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Fig. 1. Compositional verification 



2 Compositional Specification 

In this section, some preliminaries are introduced to specify and to model com- 
ponent’s behaviours. Then a constraint synchronized product is introduced to 
specify the synchronized behaviours of components. Finally, we define an ex- 
panded component and we establish a link between the constraint synchronized 
product and the expanded components. 

2.1 Preliminaries 

We introduce interpreted labelled transition system to specify component’s be- 
haviours and properties. Let V = {X \, . . . , Afy} be a finite set of variables with 
their respective domains Bi, . . . , B n . Let APy = {W = v\Xi £ V A v £ Ofy be 
a set of atomic propositions over V. 
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Definition 1 (Labelled Transition System (LTS)). A LTS S over V is a 
tuple ( Q,Qo,E, T,l ) where 

- Q is a set of states, 

- Qo C Q is a set of initial states, 

- E is a finite set of transition labels (actions), 

-TCQxExQ is a labelled transition relation, 

- I : Q -> 2 APv is a function that labels each state with the set of atomic 
propositions true in that state; we call l the interpretation. 

Let 2 be a state universe. The set of states Q of S is the subset of the 
reachable states of Q from Qo , using T (we denote q A q' an element of T). 
The set SPy = {sp, spi, sp 2 , . . .} of state propositions over V is defined by the 
following grammar: sp±, sp 2 '■'■= ap \ spi V sp 2 \ ~<spi, where ap £ APy. 

Definition 2 (sp holds on q). We define a state q £ Q satisfies a state propo- 
sition sp £ SPy, written q |= sp, as follows. 

~q\=apijfap£ l(q), 

- q \= ~^sp iff it is not true that q |= sp, 

- q\= spiV sp 2 iff q\= spi or q \= sp 2 - 

We call invariant a proposition sp £ SPy which holds on every state of S, i.e. 
\/q. (q £ Q => q |= sp), notice S |= sp. 



cs = unkn 



ejectC 



insei-tC ejectC 



(cs = reader y 
V cp = input J 

■..receiveCfeendC 



(cs = sender ^ 
l cp = input J 




Fig. 2. Protocol T=1 components CardA and DeviceA 



T=1 is a half duplex block transmission protocol between an Integrated 
Chip Card (ICC) and a Reader Interface Device (IFD) [12]. Figure 2 presents 
two LTSs, CardA and DeviceA, for the ICC and the IFD. The whole system, 
Protocol a, can be obtained from both LTSs CardA and DeviceA- 

The variables cs and cp of the LTS CardA specify respectively the Card 
Status ( unknown , sender or reader) and the Card Position ( input or output). 
The card may be inserted or ejected (actions insertC and ejectC). The card can 
alternatively receive or send blocks of messages (actions receiveC and sendC). 
The variables ds and de of the LTS DeviceA specify respectively the Device 
Status and the Device Exchange status ( ready or progress). The IFD can be 
initialised or aborted (actions initD and abortD). It can alternatively receive or 
send blocks of messages (actions receiveD and sendD), and communicate with 
other devices (actions exchD and endD). 
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2.2 Constraint Synchronized Product 

In order to specify interactions between components, we define a synchronization 
set. This set contains tuples of labels with feasibility conditions constraining 
activations of transitions the labels of which are in the synchronization set. Let 
’ denote the Active action “skip”. 

Definition 3 (Synchronization Set). Let S i = ( Qi, Qoi, LA, Tj,b ) over V\ 
and S2 = ( Q21 Q02, E 2 , 12,^2 ) over V2 be two LTSs. A synchronization set syn 
is defined as a subset o/{((e 1,62) when sp)| e\ £ EiU{— }Ae2 £ — }Asp £ 

SPv iuv 2 }- 

The whole system is a rearrangement of its separate parts, i.e. the components 
and their interactions. This arrangement is specified by a constraint synchronized 
product. To do this, we need to extend Definition 2 to pairs of states. 

Definition 4 ( sp holds on (</i , < 72 )) - We define a state (gi,g 2 ) £ Qi x Q 2 
satisfies a state proposition sp £ SPy 1 uy 2 > written (<?i , <72) |= sp, as follows. 

~ ( 9 i, 92) b S P iff sp £ SP Vl and gi f= sp, 

~ ( 9 i, 92) b sp iff sp £ SP V2 and q 2 |= sp, 

- (QI1Q2) \= ~^sp iff it is not true that (91,92) 1= sp, 

~ ( 9 i, 92) b spi V sp 2 iff either (91, 92) b s Pi or (91, 92) b S P2- 

Definition 5 (Constraint Synchronized Product). Let S\ and S2 be LTSs. 

Let syn be their synchronization set. The constraint synchronized product of S 1 
and S 2 , written S 1 x syn S 2 is the tuple ( Q,Qq, E,T,l } where Q C Q\x Q2, 
Qo C Q01 x Qo2j E C ( Ei U {— }) x (E 2 U {— }), l((qi t 92)) = h(qi) U l 2 (q 2 ) and 
T C Q x E x Q obeys the following rules. 



9i ^ 9i £ T 1 ,(q 1 ,q 2 ) b S P 
(91,92) (9 i, 92) £ T 



if ((ei,— ) when sp) £ syn 



[5.2] 



92 ^ 92 € ^2,(91,92) b sp 
(91,92) (91,92) G T 



if ((— ,e2) when sp) £ syn 



[5.3] 



9i 



9i e Ti, 92 ^ 92 € r 2 , (gi, 92) b sp 
(91,92) (e -^ 2) (9i,92) G T 



if ((ei,e 2 ) when sp) £ syn 



This definition of composition is more expressive than the classical synchro- 
nized product defined by Arnold and Nivat [6, 5] because of feasibility conditions. 
Our composition models synchronous and asynchronous behaviours. Indeed, each 
transition of the product can involve either joint transitions of two components 
or single transition of one component with respect to the synchronization set. 

The synchronization set synA given in Fig. 3, specifies the authorized be- 
haviours of the whole system Protocol a = Card a x synA Device a (see Fig. 4) 
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that can be built by Definition 5. The first action is the initialisation of the IFD 
before the card insertion. Then, components can communicate. 



(— ,initD) when ( cs = unknown ) A ( cp — output ), 
(insertC,— ) when ( ds = sender ) A ( de = ready), 
(receiveC,sendD) when (cs 7^ ds), 
(sendC,receiveD) when (cs 7^ ds), 

(ejectC, — ) when (ds — unknown) A (de — ready) 
(— ,exchD) when (cs 7^ ds) A (cp — input), 

(— ,endD) when (cs 7^ ds) A (cp = input), 

( — ,abortD) when (cs 7^ ds) A (cp = input), 



Fig. 3. Protocol T=1 synchronization set 



Alternation of messages is specified 
by synchronization between action re- 
ceiveC of CardA and action sendD of 
Device a, and by synchronization be- 
tween action sendC of CardA and ac- 
tion receiveD of Device a- The IFD can 
exchange with other devices only if the 
card is inserted. The IFD must abort 
before the ICC is ejected. 




2.3 Expanded Components 

Each component is a context-free component. However, there is a need to take 
its environment into account. For that, we define an expanded component, that 
is a component in the context of the other components under a synchronization 
set. 

Definition 6 (Expanded Component). Let S\ and S 2 be two LTSs. Let syn 

be their synchronization set. The expanded component corresponding to S 1 is 
defined by the tuple ( Qf, Qoi> Ef, Tf, if ) where 

- QiQQix Q 2 , 

~ Qoi ^ Qoi X Q 02 , 

- = {(ei, efi) | ((ei, e 2 ) when sp) G syn A ei G Ei A e 2 G E 2 U {— }}, 

“ 92)) = Mm) C ^2(92), 

- Tj c C Q\ x Ef x Q1 is obtained by Rules [5.1] and [5.3]. 

The expanded component is similarly defined. Notice that both expanded 
components are over the same set of variables V\ U V 2 . We define a sum of two 
LTSs in the same context, i.e. over the same set of variables V. 

Definition 7 (Sum of Two LTSs). Let S\ = ( Qi, Qoi, E\, Tj, l\ ) and S 2 = 
( Q 2 , Qo 2 , E 2 , T 2 , l 2 ) be two LTSs over V . The sum of Si and S 2 , written Si^tlS 2 , 
is the tuple ( Qi U Q 2 , Qoi U Qq 2 , Ei U E 2 , Ti U T 2 , l ) where l is defined by 

l( q ) = | i/g G Q 2 ’ aUd V?1 G ( ^ lV ' ?2 G < ?2-(gi = q 2^ h( q i) = h{ q 2))- 
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We have shown in [13] that Definition 7 allows us to link components and 
expanded components by: 

Si x syn S 2 = St W S 2 C (1) 



For example, we can build expanded components Card A and Device C A for 
the protocol T=1 (see Fig. 5 and 6). We have Protocol a = Card c A 1±) Device A 
thanks to Equality 1. 




Fig. 5. Expanded component Card A Fig. 6. Expanded component Device A 



Formal framework of expanded components above can be compared with 
the assume- guarantee paradigm (see for instance [9,18,19,10]). In both cases, 
one wants to take the component’s environment into account. In the assume- 
guarantee paradigm, it is expressed by hypotheses on the component’s environ- 
ment. In our approach, it is done by increasing a component model to obtain 
an expanded component. Notice that it is not the designer’s task to build the 
expanded components nor their sum. As they can be automatically generated 
by Definitions 6 and 7, the designer only needs to specify both components and 
their interactions, i.e. their synchronization set. 

3 Verifying Compositional Invariants 

In this section, we show that the synchronized component-based systems model 
is well-adapted to a compositional verification of invariance properties, called 
local and global invariants. These invariants are expressed in the propositional 
logic as state propositions (see Def. 2). Consider two components Si over V% 
and S2 over V2, and their constraint synchronized product Si x syn S2. Roughly 
speaking, a local invariant / concerns only variables in V\ (resp. V 2 ) and relates to 
states of Si (resp. S 2 ). A global invariant /' is defined over V\ U V 2 and expresses 
the authorized states of Si x syn S 2 . 





Verifying Invariants of Component-Based Systems through Refinement 295 



3.1 Composing Local Invariants 

In this section, we present some simple compositional results which are quite 
standard and trivially follow from the definition of the constraint synchronized 
product. 

Theorem 1 states that a local invariant related to component’s states, is 
preserved on the whole system thanks to the constraint synchronized product. 
The idea is the following. Local invariant concerns only variables assigned by the 
component. The only manner to modify the variables’values - in the component 
or in the whole system - is to take the component’s transitions into account. 
This way, we can state a theorem about the preservation of local invariants for 
the whole system. 

Theorem 1 (Preserving Local Invariant). Let Si over V\ and S 2 over V 2 
be two components. Let syn be their synchronization set. Let I\ € SP\ \ be a Si 
local invariant. Then we have 



Si Mi 

Sl X syn S 2 |= 1 1 

Proof by contradiction using Definitions 2, 4 and 5, and the predicate calculus. 

Generally when several invariants are verified on the whole system, they 
cannot be composed: if Si |= Ii and S 2 |= I 2 , we can only conclude that Si||jf >2 |= 
h V I 2 . In the case of our constraint synchronized product, S 1 (resp. S 2 ) assigns 
values to Vi (resp. V2) variables and the local invariant Ii (resp. I 2 ) relates to 
only these variables. This is why the stronger predicate Ii A I 2 is an invariant 
for *Sd x S y n S 2 . 

Theorem 2 (Composing Local Invariants). Let S 1 over Vi and S 2 over V 2 
be two components. Let syn be their synchronization set. Let h £ SPy 1 and 
I 2 € SPy 2 be respectively Si and S 2 local invariants. Then we have 

Si\=h, S 2 \=I 2 

S 1 X S y n S 2 |= /'I A 1 2 

Proof by Theorem 1 and the A- introduction rule of the sequent calculus. 

Theorems 1 and 2 provide a method to verify local invariants in a composi- 
tional manner without building the whole system. The constraint synchronized 
product of n components being defined in [13], both theorems can be given for 
n components. 

For our running example, the invariant I card. = (cs = unknown => cp = 
output) expresses that if the card status is unknown, then the card is ejected, 
whereas the invariant iDevice == (de = progress =>■ ds € {sender, reader}) ex- 
presses that the device does not abort when it communicates with other devices. 
It is easy to check that Icard holds on Card a, and I Device holds on Device a- 
By Theorem 2 Icard A IDevice holds on ProtocolA- 
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3.2 Verifying Global Invariants 

We show in this section that global invariants can be checked compositionally 
too. A global invariance property holding on all expanded components of a sys- 
tem, holds on the whole system. 

Theorem 3 (Verifying Global Invariants). Let Si over V\ and S- 2 over V 2 
be two components. Let syn be their synchronization set. Let I £ SPy 1 uv 2 be a 
global invariant over V\ U V 2 . Then we have 

SI h I, Sij h I 
St a s 2 c h / 

Proof by contradiction using Equality 1, Definition 2 and Definition 1. 

Theorem 3 allows us to verify a global invariant of the protocol T=l. Ip ro toi = 
( cp = output => ds £ { unknown , sender}) expresses that if ICC is ejected, then 
IFD is aborted or reinitialised. Ip ro to 2 = (de = progress => cp = input) ex- 
presses that ICC cannot be ejected when IFD communicates with other devices, 
and I Proto'S == (ds ^ unknown => (( ds = sender A cs = reader) V (ds = 
reader A cs = sender))) expresses that there is an alternation of messages (in 
fact, an alternation of status) between ICC and IFD. These global invariants 
hold on Card c A and on Device c Al so they are valid for Protocol a- 

In [4], a compositional verification approach of some CTL properties using 
a model like expanded components, is proposed. These properties are viewed as 
universal or existential properties and rules for their compositional verification 
are given. Notice that the composition operator in [4] and our constraint syn- 
chronized product are different because of synchronized transitions. Moreover, in 
our approach checking global invariants can be done during a model exploration 
of all the expanded components to verify the refinement. This is the matter of 
the next section. 

4 Invariants Verification through Refinement 

In this paper, we deal with specification and verification of component-based fi- 
nite state systems supporting a top-down refinement paradigm. The refinement 
relation we consider in this paper, is inspired by the syntactic and semantic con- 
cepts of the B refinement method [1,2]. More, our refinement paradigm guaran- 
tees preservation of the abstract system PLT L properties for the refined system 
as shown in [11], 



4.1 Basic Transition Systems Refinement 

In [8], the refinement semantics has been expressed as a relation between tran- 
sition systems. In this section, we give some basic definitions about LTSs refine- 
ment. 




Verifying Invariants of Component-Based Systems through Refinement 297 



Let SA = ( Qa,Qoa, Ea,Ta,Ia ) be an abstract LTS over Va and SR = 
( Qr,Qor, Er,Tr,Ir ) a concrete LTS over Vr. The syntactic features of the 
refinement are as follows. First, Ea C Er. Second, Va fl Vr = 0. Third, we 
have to define a gluing predicate gp expressing how the variables of both LTSs 
are linked. Let APy A \jv R be the set of atomic propositions over Va and Vr, and 
let SPv a uVr be the set of state propositions over Va and Vr. In this setting, gp 
is a propositional calculus formula over SPy A uv R ■ We define a binary relation 
ft C Qr x Q a expressing the relation between states of two LTSs 1 . 

Definition 8 (Glued states). Let gp G SPy A uv R be a gluing predicate. The 
state q R G Qr is glued to q A G Qa w.r.t. gp, written q R p q A , iff{qA,qR ) \= gp- 



The semantic features of the refinement are the following. 

1. The transitions of Sr, the labels of which are in Ea (i.e. labelled by the 
“old” labels) are kept. New transitions introduced during the refinement 
design (i.e. labelled in E R \E A ) are considered as being non-observable; they 
are labelled by r and called r-transitions. Each portion of path containing 
r-transitions must end by a transition labelled in Ea (see Fig. 7). 




Fig. 7. Path refinement 



2. In order to avoid new live-locks, new transitions should not take control 
forever. So, paths containing infinite sequences of r-transitions are forbidden. 

3. Moreover, new transitions should not introduce deadlocks. 

Definition 9 (Strict Refinement Relation [8]). Let SA and SR be LTSs, 
and e G Ea- We define the refinement relation p as the greatest binary relation 
included in p and satisfying the following conditions: 

1 ) strict transition refinement 

(QR V dA A q R -^ q' R e Tr) => 3q' A . (q A A q' A G T A A q' R p q' A ), 

2) stuttering transition refinement 

(QR V dA A q R ^ q' R £ Tr) => (q' R p q A ), 

3) lack of t- divergence 

<Ir V qA => ^ (qR —> q' R —> q'n ^ ... ^ ... ), 

4 ) lack of new deadlocks 

(QR V QA A q R -*>) => ( q A 2 - 

1 In [8], we have defined p to be a function by requiring the invariant h(s 2 ) A I 2 => 
h(s 1 ). Then, p -1 gives a partition of the state space of refined systems allowing a 
verification by parts [17]. 

2 We note q when V<?', e. (q'£QAe£E=>q-Eq'$: T). 




298 Olga Kouchnarenko and Arnaud Lanoix 



We say that SR refines SA, written SR E SA, when \/q R . {q R £ Qr => 
3q A . {qA € Qa A qR rj q A )). 

It has been shown in [8] that ?y is a kind of r-simulation. It is well-known that 
a simulation can be computed iteratively for finite state systems. We have an 
algorithm based on a depth-first search enumeration of the reachability graph of 
the refined system. Its complexity order is 0(|Si?|) where \SR\ = \Qr\ + |Tr|. 
However, it is well-known that the algorithmic verification quickly meets its 
limits when applied to huge systems. Therefore, we have to face the problem 
of combinatorial explosion during refinement verification. Details introduced by 
refinement tend to drastically increase the number of states of the system. Com- 
positional approaches partially postpone this problem. 



4.2 Compositional Component-Based Systems Refinement 

In [13] we conciliate the synchronized component-based specification with the 
refinement verification. In this section we briefly recall a refinement relation for 
synchronized component-based systems. 

Definition 10 (Weak Refinement Relation). Let S' A and SR be two LTSs, 
and e £ Ea ■ Let D C Q R (initially D = 0) be the set of new deadlocks. We 
define the weak refinement relation i)f as the greatest binary relation included 
in /i and satisfying conditions 1), 2) and 3) of Definition 9 and the following 
condition: 

4’) old or new deadlocks 

(QR Vf QA A q R ^)=> (( q A ^) V {q A q' A £ T A => q R £ D)). 

We say that SR weakly refines SA, written SR Ed SA, when Vq R .{q R £ Q R => 
3<L4- {qA G Qa A q R r/f qA))- This relation is weaker than the refinement relation 
defined in [8]. It is easy to see that 

{SR E SA) & {SR Ed SA A D = 0) (2) 

Moreover, in [13], we give a theorem ensuring refinement of the whole system 
from weak refinements of its expanded components, and vice versa. In this paper, 
we express this result using a deadlock reduction. The idea is the following. 
Some deadlocks result from the omitted details when building the expanded 
components. A state inducing a new deadlock in an expanded component does 
not induce a deadlock in the whole system if there is an expanded component 
where this state is not a deadlock state. 

Definition 11 (Reduced Deadlocks). Let SA\, SR 2 , SR\ and SR 2 be re- 
spectively two abstract and two refined components. Let syn and syn' be two 
respective synchronization sets. We have SR( Edi SA\. The reduced deadlock 
set RD\ corresponding to D\ is defined by: 

RD 1 = D\ \ {q | q £ Di A 3e2- (e 2 £ E 2 A ((-, e 2 ) when p) £ syn 1 Ag^p)} 
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Notice that this deadlock reduction is independent of the other expanded 
components. The reduced deadlock set RD^ corresponding to Dn can be com- 
puted similarly. If RD\ and RD 2 are empty, then RD\ URD 2 is also empty and, 
by Equality 2, the strict refinement of the whole system is ensured. 

Theorem 4 (Compositional Refinement). Let SA\,SA 2 , and SRi . SR 2 be 

respectively two abstract and two refined components. Let syn and syn' be two 
respective synchronization sets. Then we have 

SRi Q Dl SAj, RDi = 0, SR c 2 Qp 2 SA c 2 , RD 2 = 0 
SRl X S yn SR 2 E SAi X syn sa 2 



This theorem can be given for n components. It provides a compositional refine- 
ment verification algorithm based on the computation, for each refined expanded 
component SR^, of the relation ijf. The complexity order of this refinement verifi- 
cation algorithm is 0(|5i?i| + |5i?2l + - ' |). However, the greatest memory 

space used by the computation is max(\SR\\, ISlRfjl, • • • , \SRf |), at most. Indeed, 
the building of an expanded component, the weak refinement verification and 
the deadlock reduction can be done sequentially for each component. Thus, this 
memory space is, in the worst case, the one of the constraint synchronized prod- 
uct. 

4.3 Invariance Properties Verification 

In general, behavioural properties established for an abstract system are not 
preserved when the system is refined to a richer level of details. It is not the case 
in our approach. Indeed, we show in [11] that our refinement relation preserves 
the abstract system’s PLTL properties. This way, an algorithmic verification of 
the refinement by model exploration can be associated with a PUT L properties 
verification by model-checking. Invariance properties can be expressed by PLT L 
properties like dsp, where sp is a state proposition. Our component-based re- 
finement ensures preservation of this kind of abstract properties for the refined 
system (see Fig. 1). 

Definition 12 (sp is preserved). Let qa G Qa and qr € Qr be two states. Let 
gp G SPv a uVr be a gluing predicate. We define a state proposition sp G SPy A to 
be preserved for qr, written qr \= gp sp, iff q a |= sp and qppqA- 

It’s easy to see that the following holds. 

Proposition 1 (Abstract Invariant Preservation). Let SA and SR be two 

LTSs. Let qp € SPv. uVn be their qluinq predicate. Let I a be from SPv.- If 
SR C SA and SA |= Ia then SR h,” I a 

Invariants checking can be done during the refinement verification step with- 
out increasing complexity of the corresponding algorithm. Actually, the ideas 
are as follows. 
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- Local invariant can be checked on-tlre-fly while building the corresponding 
expanded component. By Theorems 2, 4 and Proposition 1 we also have the 
following preservation result 

SRi X syriR SR2 E SAi X syn A SA 2 , SA\ |= Jj, SA 2 |= I 2 
SRl X S yn R SR2 (= gj) 1 1 A I2 

- Global invariant can be checked during the model exploration step of the weak 
refinement verification for each expanded component. By Theorems 3, 4 and 
Proposition 1, we obtain 

SRi x synR SR 2 E SAi x synA SA 2 , SA\ |= J, SA% |= I 

SR\ X S yn SR 2 \=gp I 

To summarise, abstract system invariance properties can be used as hypothe- 
ses to ensure their preservation for the refined system. Moreover, they can be 
expressed on Vr while refining these properties like in [7]. 

4.4 T=1 Protocol Refinement 

This section illustrates the refinement by mean of the protocol T=l. Suppose 
that different blocks are exchanged between the ICC and the IFD: I-blocks for 
each piece of Information, R-blocks for Ready Acknowledgement blocks, and S- 
blocks for Supervisory Transmission control blocks. We assume that information 
to be sent is divided into 64 I-blocks (LEN). For every I-block, its reception 
is acknowledged by a R-block sent as a response. The S-block is sent when all 
I-blocks have been sent. The IFD sends all 64 I-blocks before the ICC sends its 
I-blocks. 

The ICC is refined by the Cardin component. 

Variables cs and cp are refined, and two new vari- 
ables cir and cis are introduced. Here cir is a Card I- 
block Received counter whereas cis is a Card I-block 
Sent counter. We observe the begin of insertion or 
ejection of ICC (stlnsertC and stEjectC). Four new 
transitions (receivelBC, receiveRBC, sendIBC and 
sendRBC) are introduced to receive or to send I- 
blocks and R-blocks. Figure 9 shows a part of Cardn, 
and the refinement relation relRef between Cardn 
and Card a- The entire system Card } 1 cannot be drawn here because of its size 
(see Fig 8). 

In the same manner, IFD is refined to obtain LTS Device r. Then, a refined 
synchronization set synR and two gluing predicates gpcard and gp Device are 
given to build the refined expanded components Card c R and Device C R . We have 
ProtocolR = Cardn x S yn R DeviceR = Card R l±! Device j j. The weak refinement 
relation is computed between Card c R and Card c A , and between Device R and 
Device C A . Deadlock sets are reduced. Finally, we conclude using Theorem 4 that 
ProtocolR refines Protocol a- 
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Fig. 8. Protocol T=1 
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Fig. 9. Protocol T=1 component CardR C CardA 



All invariance properties which have been verified compositionally on the 
abstract system Protocol a (see Section 3), are preserved on the refined system 
Protocol r. Since Protocol p C Protocol a, local invariants Icard and I Device and 
global invariants Ip ro toi, Iproto2 and Ip ro to3 are automatically verified by preser- 
vation on Protocolp. Moreover, the invariant Icard R = ( csp = unknown => 
cpp £ {output, toln}) can be proved trivially using Icard and gpcard as hy- 
potheses. 



5 Conclusion and Perspectives 

Compositional design and refinement paradigms are very convenient to specify 
and to verify large embedded reactive systems such as automatic trains, car 
driving assistance systems or communication protocols. 

On one hand, a compositional specification method allows us to ensure refine- 
ment of a whole system from weak refinements of its expanded components, and 
vice versa. Although expanded components seem comparable with the whole 
system, they are generally smaller than the whole system (see Fig. 8, Fig. 10 
and Fig. 11). Notice that the size of expanded components depends on both 
synchronous and asynchronous transitions from the synchronization set. On the 
other hand, we want to postpone the model-checking blow-up by verifying in- 
variance properties in a compositional way. 

The refinement relation provides a formal framework for verifying reactive 
systems. When the refinement holds, most of the properties that have been 
verified on the abstract model are preserved by the refined one (see Fig. 1). 

In this paper, we propose a technique to take advantages of the constraint 
synchronized product to verify invariance properties. We give three theorems 
allowing us to verify local invariants or global invariants, in a compositional 
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way. Our refinement paradigm is close to the B event systems one [1,2]. In the 
B method, refinement is verified by proof. Safety properties, expressed by an 
invariant, are also verified by proof. 

One of the advantages of our approach is that the 
compositional refinement relation can be verified for fi- 
nite state systems using an algorithmic method. There- 
fore, this allows verifying both refinement and invariants 
by model exploration. Another advantage of our method 
is the invariance properties preservation through refine- 
ment. 

An analysis tool related to our compositional refine- 
ment verification has been implemented [15] 3 . This tool, 
called SynCo, allows us to measure the efficiency of our 
approach. Component specifications are given in the syn- 
tax of Fair Transition Systems (FTS 4 ). Our tool builds 
the expanded components and verifies sequentially their 
weak refinement. During components and expanded com- 
ponents building, local and global invariants are checked 
without increasing the algorithm’s complexity. When the 
refinement is not verified, our tool finds the origin of the 
error. As far as we know, there are other compositional 
tools implementing reachability compositional verifica- 
tion [16] or invariant and trace refinement checking [3]. 

However, they are designed for a very different purpose 
than SynCo and, thus, do not combine compositional 
refinement with compositional invariant verification and 
preservation. 

We want to extend our compositional framework to 
take some PLTL properties’patterns into account. It 
could be done in the same manner than in [4]. More 
generally, we intend to exploit works on a verification 
by parts [17] and dynamic property refinement [7] in the 
framework of the component-based system development presented in this paper. 
We hope to extend the class of properties that can be verified in a compositional 
way. 
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Abstract. In UML 2.0 sequence diagrams have been considerably ex- 
tended but their expressiveness and semantics remains problematic in 
several ways. In other work we have shown how sequence diagrams com- 
bined with an OCL liveness template gives us a much richer language for 
inter-object behaviour specification. In this paper, we give a semantics 
of these enriched diagrams using labelled event structures. Further, we 
show how sequence diagrams can be embedded into a true-concurrent 
two-level logic interpreted over labelled event structures. The top level 
logic, called communication logic, is used to describe inter-object speci- 
fication, whereas the lower level logic, called home logic, describes intra- 
object behaviour. An interesting consequence of using this logic relates 
to how state-based behaviour can be synthesised from inter-object spec- 
ifications. Plans of extending the Edinburgh Concurrency Workbench in 
this context are discussed. 



1 Introduction 

One of the major changes made to UML 2.0 with respect to its previous versions 
concerns sequence diagrams which have been extended to include a number of 
features borrowed from Message Sequence Charts (MSCs)[ll] and, to a limited 
extent, Live Sequence Charts (LSCs)[4]. As a consequence, UML’s sequence di- 
agrams are now more expressive and fundamentally better structured. However, 
there are still several problems with their informal description in the UML 2.0 
specification [8]. 

A major change in sequence diagrams is that interactions can be structured 
using so-called interaction fragments. There are several possible fragments, for 
example, alt (alternative behaviour), par (parallel behaviour), neg (forbidden 
behaviour), assert (mandatory behaviour - though we will mention some ambi- 
guities in the specification concerning this fragment), and so on. Compared to 
LSCs, sequence diagrams in UML 2.0 can still not adequately distinguish be- 
tween mandatory and possible behaviour. For instance, it is still not possible to 
distinguish between a message that if sent may or must be received, or to en- 
force progress of an instance along its lifeline. To address this limitation we have 
proposed in [2] to enrich a sequence diagram with liveness constraints expressed 

* Work reported here was supported by the EPSRC grant GR/R16891. 
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in UML’s Object Constraint Language (OCL) using an OCL template defined 
in [1], The template is written in the context of a Classifier or Type (as OCL 
constraints generally are) and consists essentially of an after: clause followed 
by an eventually: clause. The idea is that whenever the after clause holds, at 
some point in the future the eventually clause must hold. 

The contribution of the present paper is twofold: on the one side we pro- 
vide a semantics to UML 2.0 sequence diagrams (as well as liveness enriched 
sequence diagrams), and on the other side provide a means for reasoning about 
the specified inter-object behaviour. We also envisage verification of scenario- 
based inter-object behavioural models with respect to state-based behavioural 
models. For this purpose we are currently extending the Edinburgh Concurrency 
Workbench (CWB) 1 . We discuss the extension at the end of the paper. 

In this paper, we give a semantics to sequence diagrams using labelled event 
structures [10]. We show how to construct such a model from a sequence diagram. 
Event structures allow us to describe distributed computations as event occur- 
rences together with relations for expressing causal dependency, called causality , 
and nondeterminism, called conflict. In addition, from these relations a further 
relation for denoting concurrency is derived (events not related by causality or 
conflict are necessarily concurrent). The causality relation implies a (partial) 
order among event occurrences, while the conflict relation expresses how the oc- 
currence of certain events excludes the occurrence of others. Essentially, event 
structures constitute a simple and very natural model to capture the behaviour 
specified in a sequence diagram. Further information from a sequence diagram 
is attached to the formal model in the form of labels (messages, state invariants, 
etc.). 

Further, we also show how a sequence diagram can be specified as a collection 
of formulae in a true-concurrent two-level logic interpreted over labelled event 
structures. The top level logic, called communication logic, is used to describe 
inter-object specification. It can be understood as a way to model an observer 
of the interaction, for example that whenever a message is sent it is always 
eventually received; or that certain interactions are happening concurrently. By 
contrast, the lower level logic, called home logic , describes intra-object behaviour. 
It can be used to capture local state invariants, interaction constraints, and the 
interaction from a local perspective. Additionally, OCL liveness constraints are 
translated into our communication/home logic depending on whether they corre- 
spond to a global (observer viewpoint) or a local (instance viewpoint) constraint. 

The paper is structured as follows. In Section 2, we give an overview of se- 
quence diagrams in UML 2.0. In Section 3 we introduce our underlying semantic 
model, namely labelled event structures, and show how to build a model for a 
given sequence diagram. In Section 4, we describe a simple distributed concur- 
rent logic for reasoning about the specified inter-object behaviour and imposing 
further interaction constraints. The paper finishes with some concluding remarks 
and ideas for future work. 



For information on the tool see http://www.lfcs.inf.ed.ac.uk/cwb/ 
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2 Sequence Diagrams in UML 2.0 

Graphically, a sequence diagram has two dimensions: the horizontal dimension 
represents the instances participating in the scenario; the vertical dimension 
represents time. Objects have a vertical dashed line called lifeline. The lifeline 
represents the existence of the instance at a particular time; the order of events 
along a lifeline is significant denoting the order in which these events will occur. 

A message is a communication between two instances that conveys infor- 
mation with the expectation that action will ensue. A message will cause an 
operation to be invoked, a signal to be raised, or an instance to be created or 
destroyed. Messages are shown as a horizontal arrows from the lifeline of one 
instance to the lifeline of another instance. A message specifies not only the kind 
of communication between instances, but also the sender and receiver event oc- 
currences associated to it. 

UML 2.0 sequence diagrams may contain sub-interactions called interaction 
fragments which can be structured and combined using interaction operators. 
The semantics of the resulting combined fragment depends upon the operator 
and is described informally in the UML 2.0 superstructure specification [8]. Below 
we give the meaning of some operators used in this paper as defined in [8] : 

alt designates that the fragment represents a choice of behaviour. At most one 
of the operands will execute. The operand that executes must have a guard 
expression that evaluates to true at this point in the interaction, 
par designates that the fragment represents a parallel merge between the be- 
haviours of the operands. The event occurrences of the different operands can 
be interleaved in any way as long as the ordering imposed by each operand 
as such is preserved. 

seq designates that the fragment represents a weak sequencing between the be- 
haviours of the operands, i.e. the ordering of event occurrences within each 
of the operands are maintained whereas event occurrences on different life- 
lines from different operands may come in any order, and event occurrences 
on the same lifeline from different operands are ordered such that an event 
occurrence of the first operand comes before that of the second operand, 
neg designates that the fragment represents traces that are defined to be invalid. 
All interaction fragments that are different from negative are considered 
positive meaning that they describe traces that are valid and should be 
possible. 

assert designates that the fragment represents an assertion. The sequences of 
the operand of the assertion are the only valid continuations. 

We borrow some concepts introduced in LSCs that are important to derive 
a semantic model, but are currently missing in sequence diagrams. The lifeline 
of an instance consists of several points called locations corresponding to the oc- 
currence of events. All instances have at least three locations: an initial location, 
a location corresponding to the beginning of the main chart (the whole diagram 
for sequence diagrams), and a final location. Locations are also associated with 
the sending and receiving of messages, the beginning and the end of subcharts 
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(interaction fragments for sequence diagrams), and the evaluation of a condition 
or an assignment. The locations along a single lifeline are ordered top-down; 
therefore, a partial order is induced among locations determining the order of 
execution. 

Another notion important for LSCs is temperature. Every element in an LSC 
has a temperature which can be either hot or cold. This is used to distinguish 
between possible (cold) and mandatory (hot) elements and behaviour. An ele- 
ment can be a location, a message and a subchart. Consequently, if a location is 
lrot/cold it must /may be reached; if a message is lrot/cold it must /may be re- 
ceived after it has been sent; and if a subchart is lrot/cold it describes a collection 
of interactions that must /may happen. 

Sequence diagrams can only express the possibility that a certain scenario 
occurs. That is, sequence diagrams model behaviour in the form of possible inter- 
actions, i.e. communication patterns that may occur between a set of instances. 
Furthermore, sequence diagrams, in their current setting, seem to be able to 
express necessity only to a very limited extent. In particular, it is not clear 
whether the intention of the new operator called assert is to specify mandatory 
behaviour. The superstructure specification is ambiguous in the definition of this 
operator, and it is not obvious from the text whether this operator enforces a 
sequence of messages to happen, or they are “expected” to happen (see [8], pages 
412, 442). However, even if the former case were the intended one, it would still 
only solve the problem of expressing necessity in sequence diagrams at the inter- 
action level, but not at the local level of a single message or location. Messages 
and locations in sequence diagrams are implicitly cold. If sent a message may be 
received, but it does not have to be. Similarly, any location in a sequence dia- 
gram may be reached but it does not have to be. This reflects that an instance 
is not actually forced to progress along its lifeline. 

To address the important dichotomy between must and may we have shown 
in [2] how to achieve necessity, both at the global and the local level, using an 
extension of OCL for liveness. The idea is that by default a sequence diagram 
only reflects possible behaviour (except for the assert operator) or possible but 
forbidden behaviour (given by the neg operator) . To impose additionally that a 
location must be reached or a message must be received, we have to enrich the 
model with corresponding liveness constraints written in an appropriate OCL 
template. A more powerful version of the template can also be used to express 
global liveness. For instance, that after a sequence of interactions has occurred, 
another sequence of interactions must occur. We omit further details on the 
OCL constraints in this paper as they are not essential. It suffices to understand 
that the OCL liveness constraints change the temperature of associated locations 
from cold to hot. 

UML 2.0 provides different kinds of conditions in sequence diagrams. 

1. An interaction constraint is a boolean expression shown in square brackets 
covering the lifeline where the first event will occur, positioned above that 
event inside an interaction operand. 
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2. A state invariant is a constraint on the state of an instance, for example on 
the values of its attributes. The constraint is assumed to be evaluated during 
run time immediately prior to the execution of the next event occurrence. If 
the constraint is true the trace is a valid trace; otherwise, the trace is invalid. 
Notationally, state invariants are shown as a constraint inside a state symbol 
or in curly brackets, and are placed on a lifeline. 

Finally, in previous versions of UML it was not possible to express that, at 
any time, a specific scenario should not occur. However, as mentioned at the 
beginning of this section, a new operator called neg has been introduced for 
this purpose in UML 2.0. Therefore, to model what is called an anti-scenario in 
LSCs, we simply place it inside an interaction fragment within the scope of a 
neg. Our semantics is only defined for sequence diagrams which do not contain a 
neg interaction fragment. The reason for this is that there is no real need to use 
such an interaction fragment to indicate forbidden behaviour. For example, as 
done in LSCs, it suffices to use a false state invariant to indicate that a particular 
scenario is not allowed. We show how to capture undesired behaviour as logical 
formulae. 

3 The Model 

3.1 Basic Definitions 

We recall some basic notions on the model we use, namely labelled prime event 
structures [10]. 

Prime event structures, or event structures for short, allow the description 
of distributed computations as event occurrences together with relations for ex- 
pressing causal dependency and nondeterminism. The first relation is designated 
causality , and the second conflict. The causality relation implies a (partial) order 
among event occurrences, while the conflict relation expresses how the occur- 
rence of certain events excludes the occurrence of others. Consider the following 
definition of event structures as in [3] . 

Event Structure. A event structure is a triple E = (Ev,—**,jf) where Ev is 
a set of events and — >*,# C Ev x Ev are binary relations called causality and 
conflict, respectively. Causality — >* is a partial order. Conflict # is symmetric 
and irrcflexive, and propagates over causality, i.e., e#e — >* e => e#e for all 
e, e , e £ Ev. Two events e, e £ Ev are concurrent, e co e iff ->(e — »* e V e — 
e V e#e ). 

From the two relations defined on the set of events, a further relation is 
derived, namely the concurrency relation co. As stated, two events are concurrent 
iff they are completely unrelated, i.e., neither related by causality nor by conflict. 
Moreover, an event structure is called sequential if the concurrency relation co 
is empty. 

In our approach to inter-object behaviour specification, we will consider a 
restriction of event structures sometimes referred to as discrete event structures. 
An event structure is said to be discrete if the set of previous occurrences of an 
event is finite. 




Modelling Concurrent Interactions 309 



Discrete Event Structure. Let E = (Ev,— »*,#) be an event structure. E is 
a discrete event structure iff for each event e € Ev, the local configuration of e 
given by J. e = {e | e — >* e} is finite. 

The finiteness assumption of the so-called local configuration is motivated 
by the fact that system’s computations always have a starting point, which 
means that any event in a computation can only have finitely many previous 
occurrences. 

Consequently, we are able to talk about immediate causality in such struc- 
tures. Two events are related by immediate causality if there are no other event 
occurrences in between. Formally, if V e e Ev( e ~ ** e ~ ** e ( e = eVe = e )) 
holds. If e — >* e are related by immediate causality then e is said to be an imme- 
diate predecessor of e and e is said to be an immediate successor of e. We may 
write e — » e instead of e — +* e to denote immediate causality. Furthermore, we 
also use the notation e — > + e whenever e — >* e and e/e . 

Hereafter, discrete event structures are designated event structures for short. 

Configuration. Let E = (Ev,—**,ff) be an event structure and C C Ev. C is 
a configuration in E iff it is both (1) conflict free: for all e, e G C, ->(e#e ), and 
(2) downwards closed: for any e € C and e G Ev, if e — »* e then e € C. 

A maximal configuration denotes a run. A run is sometimes called life cycle. 

Finally, in order to use event structures to provide a denotational semantics 
to languages, it is necessary to link the event structures to the language they 
are supposed to describe. This is achieved by attaching a labelling function to 
the set of events. A generic labelling function is as defined next. 

Labelling Function. Let E = (Ev, — **, ff) be an event structure, and L be an 
arbitrary set. A labelling function for E is a total function l : Ev — > L mapping 
each event into an element of the set L. 

An event structure together with a labelling function defines a so-called la- 
belled event structure. 

Labelled Event Structure. Let E = (Ev, — »*, ff) be an event structure, L be 
a set of labels, and l : Ev — » L be a labelling function for E. A labelled event 
structure is a pair (E, l : Ev — » L ). 

Usually, events model the occurrence of actions, and a possible labelling 
function maps each event into an action symbol or a set of action symbols. We 
see next how to use event structures for sequence diagrams in UML 2.0 and what 
labelling function we need in this case. 



3.2 Event Structures for Sequence Diagrams 

Consider the sequence diagram in Fig. 1 used here to illustrate our semantics 
for sequence diagrams. 

We define the signature of a sequence diagram in UML 2.0. 

Sequence Diagram. A sequence diagram is given by a tuple 
SD = (I, Loc, LoCi n i, Mes, E, Path, Xj) where 
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Fig. 1. An example of a sequence diagram in UML 2.0. 



— I is a set of instance identifiers corresponding to the objects participating 
in the interaction described by the diagram; 

— Loc is a set of locations', 

— LoCi n i C Loc is a set of initial locations' 

— Mes is a set of message labels ; 

— EC Loc x Mes x Loc is a set of edges where an edge (h,m, I 2 ) represents 
a message m sent from location li to location 1,2- E is such that: 

(i ) '^e=(/ 1 ,m,l 2 )£.E^i 7 ^ ^2 and 

(ii) V e= (; liTO) ; 2 ) e .E-3 e ,l 2 )^eEE^ 1 = ^1 V l 2 = W, 

— Path is a given set of well-formed path terms for the diagram. 

— TO ! is a family of I-indexed sets of constraint symbols where X = Xj nt U 
X st . 

The following table contains additional functions defined over SD and associated 
conditions. 



loc: I -> 2 l ‘ oc 


(1) Vi,jEi,i^jloc(i) n loc(j) = 0 

(2) \/ ie iloc(i) n Loa n i ^ 0 

(3) V iEl ,1, ilzElocitinLocinjll ^2 


time : Loc — > No 


(4) Vi eLo c ini time(l) = 0 

(5) Vi6/Vi li i 2 gi oc ( i ) i i 1? ti 2 tjme(b) time(h) 


loc-const : loc(i) — > 




scope : Loc — > Path 


(6) V e =(i 1 ,m,i 2 )eESCope(li) = scope{l 2 ) 


temp : E — > Boolean 
comm^synch : E — > Boolean 
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A few explanations regarding this definition. The conditions on edges state 
that (i) an edge cannot start and end at the same location, and (ii) a location 
can only be the source or target of at most one edge. The function loc associates 
to each instance a set of locations. According to condition (1), loc(i) gives the 
locations along the lifeline of i and these are unique for i. Each instance in 
a diagram has at least one initial location in Loci n i (condition (2)) and with 
condition (3) we further assume that each instance has a unique initial location 
corresponding to the start point of its lifeline 2 . 

The function time associates to each location a natural number (according to 
its position along a lifeline in the diagram) and is assumed given. Initial locations 
have associated time value 0 (condition (4)). Further, all locations of a particular 
instance have necessarily different time values (condition (5)), but locations of 
different instances can still have the same time value. Notice that time here 
does not necessarily mean occurrence time (though within a seq interaction 
fragment it does) but an implicit visual time value according to the diagram. 
Such locations can still be concurrent (if they belong to different operands in 
a par fragment) or in conflict (if they belong to different operands in a alt 
fragment). 

As we have mentioned, in a sequence diagram we may find simple constraints 
associated to locations, namely interaction constraints or state invariants. Fur- 
ther, these constraints are always local to a particular instance. Consequently, 
we introduced X t as a set of constraint symbols local to i £ I to be able to 
refer to such constraints (typically these constraint symbols will correspond to 
integer-typed attributes Xj nti or state names X sti ). We assume that for a set of 
constraint symbols A,, constraints ip £ <&( Xi ) are of the form 

ip:=x<c\c<x\x = c\x<c\c<x\y\ipf\ip 

where x € Xf nti , c is an integer constant, y € X st , is a state name. The function 
loc_const associates to each location a(n ordered) set of constraints over X t (if 
defined it is as given in the diagram). In the case of a location marking the 
beginning of an interaction fragment alt one constraint is implicitly associated 
to each possible operand. For example, location I 4 in Fig. 1 has an associated set 
of constraints given by locjconst(li) = {j.at > 0 ,j.at < 0} where j.at £ X/ nt j. 

Further, we assume a function scope that associates to each location in a 
diagram a path term. We do not define here the grammar for generating Path 
terms. It suffices to understand that path terms are encoded in such a way that 
it is possible to distinguish between a location that is: 

1. marking the beginning of an interaction fragment. Here a path term has the 
form a.par(n) for an interaction fragment par with n £ N operands. For 
example, for locations I 2 J 4 in Fig. 1 we have scopefa) = sdia.par( 2), and 
scope(l 4) = sdia.par(2)#l.alt(2). 



2 This is not an essential condition, and could be dropped for describing agent/role 
interactions. 
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2. inside an operand of an interaction fragment. Here a path term has the form 
a.par(n)#k where 1 < k < n indicates that the location is within the k-th 
operand of the interaction fragment. For example, scope(l^) = sdia.par( 2)#1 
and scope(l 5) = sdia.par(2)#l.alt(2)#l. 

3. marking the end of an interaction fragment. Here a path term has the form 
a.par(n). For example, for lg,ln we have scope(lg) = sdia.par(2)#l.alt(2) 
and scope(l n) = sdia.par(2) . 

Further, we assume that Path contains the shortest path terms of a diagram 
only, that is, a path term sdia.par(2).par(2).alt{2) is not allowed and instead 
the expected path term should be simply sdia.alt( 2). 

Condition (6) states an important property on edges, namely that the lo- 
cations involved must belong to the same scope. This due to the fact that by 
definition, messages in a sequence diagram cannot cross borders of operands or 
interaction fragments (cf. [8]). 

On edges and locations we define a function temp which returns true if the 
edge (and associated message) or location is hot and false if it is cold. A further 
function on edges is commsynch which returns true if the communication is 
synchronous and false otherwise. 

Consider an additional auxiliary function alt_occ : Loc x I — » No that given 
a location and an instance gives a natural number corresponding to the total 
number of operands of all alt interaction fragments that appear in the diagram 
above the given location and are complete (the end location of the fragment is 
also above the given location). 

0 4= l £ loc(i) fl LoCi n i 

m + altjocc{l ,i) 4= l, l € loc(i),time(l) = time(l ) + 1 

and scope(l) = a.alt(m) 

alt-Occ(l ,i) <= l, l £ loc(i ) , time(l) = time(l ) + 1 

and scope{l) ^ a.alt(rn) 

_L •<= otherwise 

The function is recursive and only defined for a pair (Z, i) where l is a location 

on the lifeline of i. For example, take location lg of Fig. 1, alt-Occ(lg, j) = 2. In 

fact, alt_occ(l,j) = 0 for all l € loc(j) with time{l) < time{lg), and alt-OCc(l,j) = 
2 for all l £ loc(j) with time(lg ) < time(l). 

We now define a model associated to an instance participating in the inter- 
action described by a sequence diagram. 

Instance Model. Let SD = (/ , Loc, LoCini, Mes, E, Path, Xj) be a sequence 
diagram and i be an arbitrary instance in I. A model for i is a labelled event 
structure Mi = (. ESi,m ) where ESi = (Evi,—>*,#i) with Evi such that there 
is an injective function evjniap : loc(i ) — > 2 Evi such that 




evjmap{l) 



{eq, . . . , ei m } 4= m = alt_occ(l , i) ^ 0 
{e/} 4= m = alt-Occ(l , i) = 0 
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For arbitrary ei 7^ eg G Evi, e\#ie2 iff either 

- 3/ e ; oc (i)e i,e 2 G ev.map(l), or 

— ^h^heioc(i ) e i G evjmapili) A eg G ev-map{l 2) A scope{l\) = a.alt(m)#k A 
scope(l 2) = a.alt(m)#n A n 7^ k A alt-Occ(li,i) = alt-Occ(lg , i) 

The local causality relation — >* is such that for arbitrary Zi , Z2 G Zoc(i) with 
time (l 1) < timeilg) and (scope(Zi) 7^ a.alt(m)#k or scope(l 2) 7^ a.alt(m)#n) 
and (scope(l 1) 7^ a.par(m)#k or scope(lg) 7^ a.par(m)#n), the following holds 

^ei Eev_map(Zi) *^e2Eea;_map(l2) A ^2 

Additionally, all events must satisfy the following 

^ e\ 1 e2,e3£.Evi€-l z H z i€-2 A ^3 ^ ~~ ’(fo A ^3) 

The labelling function /Zj : Evi — » Mes x {s, r} U 2 4,<x ’' > is a function defined as 
follows 



! (m, s) 4= 3 w= (; )TOi ; 1 ) £ £: for some l G loc(i),e G evjmap(l) 

(m, r) <*= 3 w= (; 1)m ,;)eB for some l G loc(i), e G ev.map(l) 

r <= 3 r<z $( Xi )loc_const(l) = T for some l G loc(i),e G evjmap(l ) 
J_ <t= otherwise 

Some explanations for this definition are in order. A location in a diagram 
does not correspond to a unique event in the event structure. The reason for 
this is that according to the definition of (prime) event structures the conflict 
relation propagates over causality, that is, two events that are in conflict have all 
their subsequent events also in conflict. In order to respect this, locations must 
have associated a set of events (one or more). Take Fig. 1, locations Z5, Z7 are 
within an alt interaction fragment. This means that they are mutually exclusive 
(captured by the event relation) . Exiting the interaction fragment means that 
location l 9 is reached, but this location is reached in either the case that I5 or Z7 
happened, so lg has to have two associated events, one for each of the possible 
operands chosen before (the number of events needed for a location is in fact 
given by the auxiliary function alt-occ). Naturally, all events associated to one 
location are in conflict. Locations that are ordered with respect to time have 
(some of) their associated events related by causality as long as the locations 
are not within the same par or alt interaction fragment. Take Fig. 1 again. No 
events associated to locations I3 and 1 10 are related by causality because they are 
within the same par interaction fragment. In fact they are also not in conflict 
by definition, so they have to be concurrent. Locations I5 and lg are ordered by 
time, and satisfy the conditions for the causality relation. Consequently, for all 
events associated to I5 (which is only one, say eg, because alt-Conc(lg, j) = 0) 
there is a unique event within the set evjmap(lg) (let this event be egi) such 
that eg — >* egi . 

Finally, the labelling function is defined for an event e if this event is associ- 
ated to one of the following kinds of locations: a send location (the label is (to, s) 
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where m is the message being sent); a receive location (the label is (m, r) where 
to is the message being received); a condition location, that is, a location which 
has associated an interaction constraint or a state invariant. 

The above defined model for an instance is a well-defined labelled event 
structure. We omit the proof here for space reasons. 

From the models of the instances involved in the interaction we can obtain 
a model for the entire interaction diagram given in the following definition. 

Diagram Model. Let SD = (/ , Loc, LoCi n i, Mes, E, Path, Xj) be a sequence 
diagram, and Mj = (ESi,Hi) be a model for i £ I. A model of the diagram is 
given by M = (ES, p) where ES = (Ev, — ►*, #) and Ev is defined as follows 



Ev = {e £ Evi | e £ evjmap(l) for some l £ loc(i) such that 

~^3 w( ze(w = (h,m, l)W w = (l, in, l\)) A commsynch(w) = true 
for some l\ £ Loc and m £ Ales } 



u 



{(ei,e2) £ Evi x Evj | for each e\ £ evjmap(h) there is a unique 
ei £ evjmap(l 2) for some l\ £ loc(i),l2 £ loc(j) 

iff 3 W £ew = (l\,m, I2) and commsynch(w) = true 
for some to £ Ales} 

For arbitrary e/e £ Ev, effe iff one of the following cases holds 



1. e,e £ Evi for some i £ I and e#*e 

2. e £ Evi, e £ Evj for some i ^ j £ I and e £ evjmap(h), e £ evjmap(l2), 
scope{l\) = a.alt(m)#k, scopefa) = a.alt(m)#n for n ^ k and further 
altjocc(l\,i) = alt.occ{l2,j). 

3. e £ Evi for some i £ I and e = (ei,e2) with ei £ Evj,e2 £ Evt for some 
j ^ k £ I and either: 

(a) {i= j A e#jei) or (i = k A e#je 2 ) 

(b) e and ei satisfy condition 2. above. 

4. e = (ei, 62) and e = (e l5 e 2 ) with ei £ Evi, e2 £ Evj,e 1 £ Ev p , e 2 £ Ev q for 
i yf j £ I and p ^ q £ I. e\ and e 1 satisfy the above condition 1. or 2. 



For arbitrary e,e £ Ev, e — »* e iff one of the following cases holds 



1. e, e £ Evi for some i £ I and e — »* e 

2 . e £ Evi for some i £ I and e = (ei,e2) with ei £ Evj,e2 £ Evk for some 
j k £ I. Either: (i = j A e — »* e\) or (i = k A e — »* e2) 

3. e = (ei, 62) and e = (e-^ e 2 ) with ei £ Evi, e2 £ Evj,e-y £ Ev p , e 2 £ Ev q for 
i 7^ j £ I an d Vi ^ q£ I- One of the following holds: (a) i = p and ei —>■* e x ; 
(b) j = p and e2 — e^, (c) i = q and ei — »* e 2 or (d) j = q and e2 — e 2 . 

4. there is a w £ E such that w = (l\,m,l2) for some to. £ Ales such that 
comm_synch(w ) = false, e £ evjmap(l i),e £ evjmap(l2) and -i(e#e ). 

Additionally, for all u> = (h,m, I2) £ E with commsynchlw) = false and 
temp(w) = true the following holds: 



^ei £ev-map(li) ^e 2 £ev-map(l 2)^1 



e2 
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The labelling function /z : Ev — > Ales x {s, r} U 2' Pi ' Xl ^ is defined as follows: 

M _Jm <t= e = (ei,e 2 ),ei G Ev iy e 2 G Evj,m{ei) = (m, s),/Zj(e 2 ) = (m,r) 
W “| ft (e)^eG^ 

To summarise, the above set of events Ev is such that it contains all the 
local events of the instance models except for those that belong to locations 
participating in a synchronous communication - for which pairs of events are 
built (the first argument for the send event, the second for the receive event). 
Concerning the relations, local relations propagate to the global level. Events 
are in conflict at the diagram level if they are associated to locations that fall 
within the same scope of an alt interaction fragment. New events are added 
to the causality relation, namely those that are associated to an asynchronous 
message. Here, a distinction is made between hot asynchronous messages and 
other messages, namely, for hot messages we require that a message sent must 
be received, that is, in event terms there must exist a unique receive event 
causally related to the send event. Finally, the labelling function is such that a 
synchronous communication pair of events is labelled by the message exchanged, 
and all other events are labelled with the local label (an asynchronous message 
send/receive, a set of interaction constraints or state invariants). 

The above defined model for a sequence diagram is a well-defined labelled 
event structure. We omit the proof here for space reasons. 

Consider Fig. 2, it shows an event-based model for part of the interaction 
from the diagram of Fig. 1. It shows the two possible traces in the interaction. 
Only some labels are included for increased readability: instances j and k syn- 
chronise at event ei with message m2, and at event e 2 with message m3. Event 
ei s denotes the sending of message m8, and event e P5 denotes the corresponding 
message receive. 



4 A Concurrent Communication Logic 

We describe briefly the main idea of our logic, a distributed temporal logic called 
Mdtl, and how it can be used to specify interactions. More details on the logic, 
including the semantics, can be found in [7, 6]. 

An instance involved in the interaction described by a sequence diagram SD 
has a home logic to describe internal properties (for example, state invariants 
and interaction constraints) or describe interactions from a local point of view. 
Further, a communication logic describes interactions between several instances. 
To some extent, the communication logic describes an observer of the interaction. 
The abstract syntax of Mdtl where i and k are instances, is given as follows (in 
a simplified variant for our purposes): 

Mdtl::= {i.Hi} ieI | C 

Hi ::= ATOMi | Hi \ Hi => Hi \ H t Uy Hi \ Hi U 3 Hi \ AH t 
C ::= i.Mes\ <-► fc.Mes? | i.Mes\ -► k.Mesl \ H obs 
ATOMi ::= true | <£(W) | Mes\ \ Mesl 
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instance j instance k 




(m8,r) 

®p5 

e p62 



Fig. 2. An event structure for the example interaction between j and k. 



The home logic Hi is basically an extension of CTL (notice that U\j corre- 
sponds to all paths, whilst IA 3 corresponds to there is a path) with a concurrency 
operator A. The intuition of a formula i.(<pi A Ap 2) is that from the point of 
view of instance i , ip\ holds and <p 2 holds concurrently. Mes denotes a mes- 
sage term where Mes\ is used to denote the sending of a message and Mesl to 
denote the receipt of a message. In the communication logic C, <-> is used for 
synchronous communication and — > and for asynchronous communication, and 
in both cases for denoting hot messages, that is, a message that if sent must 
be received. Notice that the communication logic can refer to H 0 b s where obs is 
used to denote an interaction observer. $(Xi) is the constraint logic introduced 
earlier in Section 3.2. 

We can use Mdtl to describe the complete interaction specified in a sequence 
diagram. Furthermore, we can impose constraints on the interaction, describe 
the forbidden behaviour associated to an interaction or that a certain collection 
of communications is mandatory (which is captured to some extent by an assert 
interaction fragment). For space reasons we just give some examples. 

Imagine that we want to state that an asynchronous hot message if sent must 
always be received. Take the sequence diagram of Fig. 1 and assume we have 
an OCL liveness constraint attached to the diagram stating that if sent message 
ml must always be received. The corresponding communication logic formula is 
written as follows: 

i.ml! — > j.mll 
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After ml has been sent and until m2 has been received no other messages are 
sent or received is given by the next communication formula. 

ml! A V ml) U\j m2!) 

Consider now, a few local statements to illustrate the home logic. The formula 
below states that 

j.(m2\ A Z\to5?) 

from the point of view of j, sending message m2 and receiving message m5 
happens concurrently (in either order or at the same time). 

After i has sent m7, i eventually reaches Statel, which can be used to denote 
internal liveness, that is, that an instance must progress along its lifeline (which 
cannot be stated directly in UML 2.0 sequence diagrams). 

i.(m7\ A ( true U\j State 1)) 



5 Conclusions 

We have given a semantics to sequence diagrams in UML 2.0 based on labelled 
event structures. The presented semantics given is not complete as we have not 
considered all interaction fragments permitted in UML (for example strict and 
loop). Extending the presented model with such fragments is straightforward. 

We have presented a simple concurrent distributed temporal logic and showed 
how interactions and various constraints can be described in this logic. There 
are essentially two ways in which we can use this logic. Firstly, to capture some 
interaction properties (e.g., forbidden behaviour, liveness properties, state in- 
variants, etc). In this case we can check whether the inter-object behavioural 
model (a labelled event structure) satisfies the properties. Secondly, to capture 
the entire interaction of a sequence diagram as a set of formulae. An interesting 
consequence of this case is that we can verify the sequence diagram against the 
state-based behavioural model directly through model checking. 

We are currently working on the integration of our concurrent logic into the 
Edinburgh Concurrency Workbench (CWB). Ultimately, our aim is to establish 
a connection between CWB and UML 2.0 enabling the verification of temporal 
formulae over behavioural models. The temporal formulae to be verified can be 
given either directly in our simple temporal extension of OCL2.0 [1,2] or in- 
directly through a sequence diagram in UML2.0, both of which translate into 
formulae in our concurrent logic. Depending on what is being verified, the be- 
haviour model itself can be given by sequence or state diagrams in UML 2.0. 

There are many variants of MSCs and high-level MSCs as well as work on 
providing a formal semantics to them. Some MSC extensions consider liveness 
properties as well (e.g., [5]), or are given a semantics based on Petri nets with 
unfoldings defined as event structures [9]. Additionally, there is a lot of recent 
work using LSCs which have a well defined operational semantics [4]. By contrast, 
our approach is based on the most recent version of the standard UML 2.0 
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using OCL 2.0 for additional liveness properties if required. We do not know of 
other work which addresses the latest extension of sequence diagrams in UML 
2.0 or explores the powerful combination of UML and OCL. We also believe 
that the underlying embedding onto a true-concurrent logic as ours is novel and 
offers interesting perspectives concerning synthesis and verification which we will 
explore in the future. 
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Abstract. This paper explains how proof support for the RAISE Spec- 
ification Language (RSL) can be obtained by reusing the Isabelle/HOL 
theorem prover. An institution for a subset of RSL is defined together 
with a light institution comorphism from this institution to an existing 
institution for higher-order logic (HOL). A translation of RSL specifi- 
cations to Isabelle/HOL theories is derived from the light institution 
comorphism and proved sound wrt. semantic entailment. Finally, the 
results of some case studies are reported. 

Keywords: Institutions, RSL, HOL, algebraic semantics, proof support. 



1 Introduction 

The RAISE Specification Language (RSL) [14] is a wide-spectrum specification 
language associated with a development method [15] based on stepwise refine- 
ment. Proving properties of specifications is important to the method and proof 
tools [4] are available. However, a higher degree of automation is desired. 

The goal of this paper is to outline how increased proof support for RAISE 
can be obtained. An approach is to use an existing theorem prover having the 
desired properties. A good candidate for that is the theorem prover Isabelle [13] 
which offers support for higher-order logic (HOL). The idea is to translate RSL 
proof-obligations to HOL and then prove the translated proof obligations using 
Isabelle. The translation must be sound in the sense that properties proved about 
the translated specifications in HOL also hold for the original specifications in 
RSL. 

An approach for defining the translation in a formal way, so that it can be 
proved sound, is to define a morphism from an institution for RSL to an insti- 
tution for HOL. The concept of institutions [16] formalizes the informal notion 
of logical systems with signatures, sentences, models, and a satisfaction relation. 
Many variants of morphisms (defining translations of signatures, sentences, and 
models) between institutions exist, cf. [8]. However, we define a new, more sim- 
ple kind, light institution comorphisms, that is sufficient for our purpose. An 
institution for HOL already exists, so our task is to define an institution for RSL 
and a light institution comorphism from the institution of RSL to that of HOL, 
and to prove that the light institution comorphism satisfies certain requirements 
that ensure the above mentioned soundness property. 



C. Rattray et al. (Eds.): AMAST 2004, LNCS 3116, pp. 319-333, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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1.1 Outline of the Paper 

First, Sect. 2 introduces the concepts of institutions and light institution comor- 
plrisms. Then, in Sect. 3 and in Sect. 4, we define institutions for a subset of 
RSL and for HOL, respectively. Next, in Sect. 5, we present a light institution 
comorplrism from the RSL institution to that of HOL, prove that it is sound wrt. 
semantic entailment, and explain how it induces a translation from RSL to Is- 
abelle/HOL. Finally, achievements, related work, and future work is summarized 
in Sect. 6. 

2 Formal Background 

In this section, we define the notions of institutions and light institution co- 
morphisms. Moreover, we explain how theorem provers may be reused via light 
institution comorphisms. 

2.1 Institutions 

The concept of institutions [16] formalizes the informal notion of a logical system. 
Definition 1. An institution I is a quadruple (Sign, Sen, Mod, |=) where 

— Sign is a category of signatures 

— Sen : Sign ► Set is a functor that maps each signature to the set of 

sentences over the signature 

— Mod : Sign ► Cat op is a functor that maps each signature to the category 

of models over the signature 

— [=i; C \Mod(E)\ x Sen(E) is a satisfaction relation for each E £ \Sign\ 
so that 

m' (=^7 Sen(a)(e) iff Mod(a)(m') |=i 7 e 

for each a : E ► E' in Sign, m' £ \Mod(E')\, and e £ Sen(E). This 

requirement is known as the satisfaction condition. 

For a category C, its collection of objects is denoted by |Cj. The notation a(e) 
is often used for Sen(a)(e), and the notation m\ a is often used for Mod(a)(m). 

2.2 Light Institution Comorphisms 

Many different kinds of mappings between institutions and names for these have 
been suggested, cf. e.g. [8] which gives a survey of this. In this section we intro- 
duce a new kind, light institution comorphisms, that are weak versions of simple 
institution representations [11]. 

In the following, let I = (Sign, Sen, Mod, [=), I ' = (Sign', Sen', Mod 1 , (=') 
be institutions and Pres' be the category of /'-presentations such that an object 
of Pres' is of the form (E',E') where E' £ \Sign'\ and E' C Sen'(E'). The 
notation Sig(P) is used for the signature of a presentation P. Furthermore, let 
Mod' denote the functor from Pres' into Cat op , for which Mod'((E' ,E')) is the 
category of the models over the signature E' that satisfy the set of sentences E' . 
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Definition 2. A light institution comorphism g : I ► I' is a triple (g,a,/3) 

where 

— g : \Sign\ ► \Pres'\ is a function that maps I -signatures to I' -presenta- 

tions 

— a = (as ■ Sen(£) «- Sen' (Sig(g(£)))) se\Sign\ is a family of functions 

— (3 = ((3s '■ \Mod'(g(£))\ ► \Mod(£)\)se\Sign\ is a family of partial func- 

tions 

so that 

m ' l=Sig( e (iJ)) a ^(e) iff (3s(m') \^ s e 
for each £ £ \Sign\, e £ Sen(E), and m! £ \Mod'(g(£))\ for which (3s(m!) is 
defined. This requirement is known as the representation condition. 

The partiality of (3s reflects that the institution /' may have a larger collection 
of models than the institution I. 

Light institution comorphisms are weak versions of simple institution repre- 
sentations 1 [11]: g is a function and not a functor. Consequently, g is not con- 
cerned with mapping signature morphisms. As a consequence, it has no meaning 
to require a and (3 to be natural. Furthermore, (3 is a family of functions and not 
a family of functors. Finally, (3s may be partial and the representation condition 
is only required to hold when (3s(m!) is defined. 

Light institution comorphisms are weaker than simple institution represen- 
tations since they do not enable reuse of theorem provers for structured specifi- 
cations built using signature morphisms. Moreover, the partiality of (3s causes 
the below Theorem 1 to be one-directional. 

The reason for using light institution comorphisms is that they enable reuse of 
theorem provers for flat specifications without requiring a mapping of signature 
morphisms and naturality of a and (3. 

The notion of institution comorphisms [8] has previously been weakened: 
Semi-natural institution comorphisms [8] relax the requirements of naturality, 
and simulations [2] allow mappings of models to be partial (but they must be 
surjective). 

2.3 The Reusing Theorem 

In this section, we describe how one can prove semantic consequences of a spec- 
ification in one institution by using a theorem prover for another institution. 

For light institution comorphisms, like for some other kinds of mappings 
between institutions (e.g. for maps of institutions [5], i.e. theoroidal institution 
comorphisms satisfying certain requirements), there is a reusing theorem: 

Theorem 1. Let (g,a,(3) : I ► I' he a light institution comorphism for 

which (3s is surjective for each £ £ \Sign\ . Then, for any £ £ \Sign\ 

(£,E)\=s<p if (£',as(E) U E') \=' s as(y) 

where g(£) = (£',E'). 

1 Simple institution representations are like simple theoroidal institution comor- 
phisms [8] except that signatures are mapped to presentations instead of theories. 




322 



Morten P. Lindegaard and Anne E. Haxthausen 



Proof. See [10]. 

If j3s is total for each £ £ \Sign\, the theorem holds in both directions, ensuring 
a sense of completeness. 

The theorem suggests the following method for proving semantic conse- 
quences for an institution I: 

1. Find another institution /' that has a sound proof system (with tool sup- 
port), i.e., 

SP' \-' E e' implies SP' \=' s e'. 

2. Define a light institution comorphism (g, a, (3) : I ► I' such that (3s is 

surjective for each £. 

3. To prove p to be a semantic consequence of a specification (£,E), trans- 
late the specification and the proof obligation p along the light institution 
comorphism into I' and use the proof system (theorem prover tool) of I' to 
prove that the translated proof obligation is a consequence of the translated 
specification. 

3 An Institution for a Subset of RSL 

RSL [14] is a wide-spectrum language which encompasses and integrates differ- 
ent specification styles (algebraic, model-oriented, applicative, imperative, and 
concurrent) in a common conceptual framework. However, for the purpose of 
providing proof support, we only consider an applicative subset, as, according to 
the RAISE method, most proofs are made in the early development steps where 
specifications are applicative. 

In this section, we first describe the chosen subset, mRSL , and then we define 
an institution for this subset. See [10] for details. 

3.1 An Applicative Subset of RSL 

An mRSL specification is a named class expression consisting of declarations of 
types, values, and axioms. 

A type declaration is either a sort declaration or an abbreviation type dec- 
laration. A sort declaration, as known from algebraic specification, introduces a 
name for a new type without specifying it any further, while an abbreviation type 
declaration declares a name to be an abbreviation for a type expression that is 
constructed in a model-oriented way from declared type names, type literals like 
Int, Real, and Bool, and type operators like x (for Cartesian products) and 
— > (for partial functions). 

A value declaration consists of a name and a type expression. 

An axiom declaration consists of a name and an equivalence expression of 
the form ve\ = ve 2 , where ve\ and ve 2 are value expressions. Value expres- 
sions include value names, value literals for the built-in types, basic expressions 
(e.g., for denoting non-termination), product expressions, A-abstractions, func- 
tion applications, infix expressions, prefix expressions, quantified expressions, 
if-expressions, and equivalence expressions. 
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Example. As an example of an (m)RSL specification, we show an algebraic 
specification of a gas burner: 

scheme GAS = 
class 

type State 

value gas : State -A Bool 
value flame : State — > Bool 
value leak : State A Bool 

axiom [leak_def] leak = (A s : State gas(s) A ~flame(s)) 
axiom [gas_total] (V s : State 3 b : Bool (gas(s) = b)) = true 
axiom [ flame_total ] (V s : State 3 b : Bool (flame(s) = b)) = true 
end 

The axioms state that there is a leak when the gas is on and there is no flame 
and that gas and flame are total functions. 



Semantics. A (well-formed) mRSL specification determines a signature, S, 
and a set of A-sentences, E, of the underlying institution (that will be described 
in next subsection). The signature is derivable from the type declarations and 
value declarations, whereas the set of sentences is derivable from the axiom 
declarations in an obvious way. 

The semantics of the specification is the loose semantics of the presentation 
(S,E), i.e. , the class of A7-models that satisfy all the sentences in E. 



3.2 An Institution for the Subset of RSL 

An institution I m RSL for the mRSL subset is defined in the following. 



Signatures. Sign m RSL is the category of signatures. 

For a set X of identifiers, T(X) denotes the set of type expressions that can 
be generated using identifiers in X , mRSL type literals, and type operators. 

A signature A is a quadruple (S, A,W,V), where S' is a set of sort names, 
A is a set of abbreviation type names, : A — > T(S U A) is a function that 
maps abbreviation type names to type expressions they are abbreviations for, 
and V is a T(S)-sorted set of value names; the sets S and A must be disjoint, 
type abbreviations must not be cyclic and the sets of V are disjoint (disallowing 
overloading) . 

Let X = (S,A, \P,V) and S' = (S' , A' ,\P' ,V') be signatures. A signature 
morphism a : S ► S' is a triple a = (as, a a, try) where 

— as : S ► S' U A! is a mapping of sort names 

— a a '■ A ► A! is a mapping of abbreviation type names 

— ay : V ► V' is a mapping of value names. 

such that 
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— the mapping ay is T(5')-sorted and respects as- 

ay = ( ay t : V t *- V# ( as (t)))teT(s ) 

where a$ is lifted to work on type expressions in T(S) by replacing oc- 
currences of sort names as prescribed by erg, and where is the function 
that takes a type expression to its canonical form by recursively expanding 
abbreviation type names as prescribed by and 

— the following diagram commutes: 



A 



OA 



A' 



I p* 



q/'* 



T(S) — T(S'UA’)-^T(S') 

Note that signature morplrisms are allowed to map sort names to sort names 
as well as abbreviation names, but abbreviation names are only allowed to be 
mapped to abbreviation names. This reflects the fact that the RAISE method 
allows sorts to be refined to concrete types, but not vice versa. 



Sentences. The functor Sen m RSL '■ Sign m RSL *- Set maps each signature 

to the set of sentences over the signature, and lifts each signature morphism to 
work on sentences. 

A £ -sentence is an equivalence expression (as defined by the mRSL grammar 
and informally described in Sect. 3.1) which is we 11- formed wrt. £ . 

Well-formedness of value expressions (and thereby also of equivalence expres- 
sions) wrt. a signature £ = (S, A, 1 F, V) is defined in the usual way by a set of 
deduction rules defining type assertions of the form £ b ve : t where A is a sig- 
nature, ve is a value expression, and t is a canonical type expression. Informally 
a value expression is well-formed if it is type correct and any value name is in V 
or an enclosing typing and any type name is in 5Ud. 

Signature morplrisms a = ( as, a a, ay ) are lifted to work on sentences by 
replacing occurrences of sort names, abbreviation type names, and value names 
as prescribed by as, a a, and ay, respectively. 



Models. The contravariant functor Mod m RSL '■ Sign m RSL ► Cat op maps 

each signature to the discrete category of models over the signature, and maps 
each signature morphism to the reduct functor between the categories of models. 

A £-model interprets each type name in A as a type and each value name 
in A as a value. Before giving the precise definition, we first define the semantic 
domains of types and values. 

For each canonical type expression t (e T(0)), there is a value domain V aluet 
which is a set of values. Inheriting terminology from full RSL, a value expres- 
sion denotes a “process” . For each type expression t, there is a process domain 
extending the value domain for t with the diverging process _L: 
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Procst = Valuet. U { _L} . 

Examples of value domains: Valuer is the set of all integers, and Value ~ 

1 1 — >t2 

is the set of all functions from Valuet 1 to Procst 2 . The process domains (rather 
than value domains) are used to give semantics to value expressions, since these 
may not terminate. 

The domain of types can now be defined: 

Types = {type \ type C Value t A type ^ 0 A t € T(0)}, 
i.e., a type is a set of values. 

Let £ = (S, A, T, V) be a signature. A £-model is a triple ( ms,rriA,mv ) 
where 

— ms : S ► Types 

— m,A : A ► Types 

— m v = K : V t - WT(S)(f))ter(S)- 

ms interprets each sort name in S' as a set in Types. Type literals and type 
operators have fixed interpretations (according to Valuet) which are used to lift 
ms to a map mx(s ) that interprets type expressions that may contain sorts in S. 

mA interprets each abbreviation type name a in A as a type in Types such 
that mA{a) = uit(s)(T * ( a ))- 

my interprets each value name in Vt as a value in the type denoted by its 
type expression t. 

Let £ = (S, A, T, V), £' = (S', A', T', V') be signatures, let a = (as, a a, fry) : 

£ *- £' be a signature morphism, and let m! = (m' s , m' A , m! v ) be a £'- 

model. Then the a-reduct m'\ a of m! is a A-model m = ( ms,mA,mv ), where 

— ms(s) = m' T ^ s )(T'*(as(s))) for all s € S 

— mA(a) = m' A ( aA(a )) for all a £ A 

— m v = ( m' v oa Vt : V t ► m' T(s AT'* {a s (t)))) tGT{S )- 

* (»s(*)) 

The Satisfaction Relation. The satisfaction relation |= is expressed in terms 
of the dynamic denotational semantics M: 

m\=s valuejexpri = valuejexpr 2 



if and only if 



Ms(m) (valuejexpri) = Ms(rn)(valuejexpr 2 ). 

The meaning function M is indexed by a signature £ so that its type is VI y : 
Mod (£ ) ► ValExpr(£) ► Procs where ValExpr(£ ) denotes value ex- 

pressions over £ and Procs is the union of process domains Procst, t (E T(0). 

A/y (to) essentially evaluates a value expression, interpreting value names as 
in the model to. The result is a process. As an example, if to interprets the value 
c as 2 , then Afy(m)(c + 2 ) denotes a process that terminates with the result 4 . 
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The Satisfaction Condition. Truth is invariant under change of notation: 
m! \=s o’(e) iff m!\ a \=s e 

for all signatures £ and £’ , signature morphisms cr : £ ► £’ , A'-models m', 

and 17-sentences e. 

Proof. By induction on the structure of e. 



Example. Consider the specification of a gas burner presented in Sect. 3.1. 
Its signature is £ = (S, A,T,V), where S = {State}, A = 0, W is the empty 
function, ^g^ a ^ e ^.g 00 j = {gas, flame, leak}, and V t = 0 for types t different 

from State Bool. Its set of sentences contains the three axioms. 



4 HOL 

In this section, we outline parts of the institution for higlrer-order logic from [3], 
and we briefly touch upon Isabelle/HOL. 

Higher-order logic, presented in [1], is based on Church’s theory of simple 
types [6] . The technical details of the institutional formulation are based on [9] . 



4.1 Institution for HOL 

We now outline those parts of the institution Ihol for HOL defined in [3] that 
are relevant for translating from mRSL to HOL. 



Signatures. SignnOL is the category of signatures as described below. 

Let TyVars be an infinite set of type variables , and Ty Names an infinite 
set of names of type constants. A type constant is a pair (u, n ) with the name 
v £ Ty Names and the arity n (a natural number). 

A type structure ft is a set of type constants (with distinct names). The set 
Types a of types over a type structure ft is generated by the grammar: 

t ::= 7 | c | (ti, ...T n )u | n -> r 2 

where 7 £ TyVars , (c, 0) € C, and (y, n) £ fl. 

A signature A is a pair (I?, C), where 17 is a type structure and C is a set of 
constants typed by types over ft (i.e., types in Typeso) such that 

— ft contains (bool, 0), ( 4 , 0), and (x,2), and 

— C contains the primitive constants = 7 ^ 7 ^h 00 ; (equality), e( 7 ^{,ooZ )^ 7 
(choice), pair^s^ij^x (pair construction), /st( 7 l a ) X ^ 7 (projection), and 
snd( 7 i 5) X ^5 (projection). 
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Sentences. For each signature £ = (17, C), the set SeriHOL(£) of sentences 
over £ is the set of closed 17-formulas, i.e. , the set of 27-terms of type bool that 
do not contain free variables. 

17-terms are formed by variables typed by types in Types o, constants in 
C, function applications, and A-abstractions in the usual way described by the 
following grammar: 



t T 



-Vt | 0 T | ( [t T — >rt r )r | (AtC Tl -t T2 ) Tl — > T2 



where the subscripts indicate the types of the terms. 



Models. For each signature 17 = (17, C), the category Mo<Ihol{£) is the dis- 
crete category of standard 17-models as described below. 

The syntax of higher-order logic comprises types and terms. Types denote 
sets, and terms denote elements of sets. The semantics is given using a fixed 
collection of sets U, called the universe , with the following properties: 

— the elements of the universe 'll are non-empty sets, 

— if S G U then l( contains all non-empty subsets of S and the power set of S, 

— U is closed under Cartesian product, 

— II contains a distinguished infinite set TruL and 

— there is a distinguished element ch G IlseuS which is a function; ch(S) G S 
witnesses that the sets S € ll are non-empty. 

The properties imply that If contains finite Cartesian products and function 
spaces. Furthermore, particular sets are selected such that If contains a distin- 
guished singleton set 1 = {0} and a distinguished two-element set 2 = {0, 1}. 

A model mo of a type structure 17 maps each type constant ( v , n) in 17 to 

an n-ary function m-oiy) : If” ► It if n > 0. If n = 0 then moiy) G It. 

A model of a signature (17, C) consists of a model mo of 17 and an interpre- 
tation me of C. If a type r contains no type variables, me maps each constant 
c T in C to an element in the set [r] mi2 which is the meaning of r wrt. mo- If 

r contains n > 0 type variables, [r] mn is a function It” ► U , and me maps 

each constant c T to a function U n ► S where S G It is a type that depends 

on the argument (in It") given to the function. 

The model is standard if 

— mo interprets bool as the distinguished two-element set {0,1}, l as the dis- 
tinguished infinite set Ind, and (x,2) as Cartesian product, and 

— me interprets the primitive constants that are required to be in a signature 
accordingly. 



The Satisfaction Relation. A standard 17-model m satisfies a 17-sentence ip, 
written m \=s <p, if and only if the meaning of ip with respect to m is 1 for all 
interpretations of type variables. 

The meaning wrt. a model m of a closed term without type variables is an 
element of a set in II and depends on the interpretation m-c of constants in 
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the term. The meaning of a term with free variables and/or type variables is 
a function that takes arguments corresponding to the interpretation of the free 
variables and type variables and returns an element of a set in 'll. 

4.2 Isabelle/HOL 

Isabelle is a generic theorem prover, i.e. , logics such as HOL can be expressed in 
the meta-logic of Isabelle. The implementation of higher-order logic in Isabelle 
(Isabelle/HOL [12]) is based on the description of HOL in [9]. A module or spec- 
ification in Isabelle is called a theory , and users of Isabelle/HOL write theories 
that extend a theory containing definitions and declarations of Isabelle/HOL. 

Considering Isabelle/HOL, it is the entailment relation (i.e., the proof rules) 
that alone defines the logic. Isabelle/HOL has eight primitive inference rules and 
a number of derived rules. Isabelle/HOL follows the standard higher-order logic 
approach of taking a few connectives as primitives and then defining the rest. 
We refer to [12] for a detailed account of Isabelle/HOL. 

5 A Light Institution Comorphism from mRSL to HOL 

To reuse the theorem prover Isabelle, we must translate mRSL specifications into 
Isabelle/HOL theories. In this section, we present a light institution comorphism 
from mRSL to HOL and describe how it provides a translation. For further 
details, see [10]. 

5.1 A Light Institution Comorphism from mRSL to HOL 

We now describe a light institution comorphism, (g, a, (3) : I m RSL ► Ihol- 

The idea is to encode the semantics of mRSL in HOL. 

Mapping Signatures, g maps an mRSL signature £ = {S, A , S', V) to a HOL 
presentation ((f2 mRS L U Q s , C mRS L U C s ), E mRS L ) where 

— ft mR SL is a type structure containing type constants: 

• (t, 0) for all mRSL type literals t 

• (P, 1) for lifting value domains to process domains 

— C mR sL is a set of typed constants for expressing the mRSL semantics in 
HOL 

— E mR sL is a set of sentences specifying the constants in f2 mR sl and C mR SL 
and 

— Os is a type structure containing type constants (s, 0) for all sort types 
s € S 

— Cs is a set containing a typed constant, v T , for each value v in V), t S T(S), 

where r = A^(f) and : T(S) — > Types o mRSL is a function trans- 

lating mRSL type expressions to HOL types (e.g., A f £(t iAf 2 ) = A f £(ti) — > 
(A t £(t 2 ))P to encode partial mRSL functions as total HOL functions). 
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Mapping Sentences. For a given mRSL signature 27, as maps mRSL 17- 
sentences (equivalence expressions) into HOL Sig(£>(27))-sentences as follows: 

as(vei = ve 2 ) = As(vei) = As{ve 2 ) 

where As is a function mapping mRSL 17-value expressions into HOL Sig{g{l 7))- 
terms that represent their semantics, i.e. , an mRSL value expression is mapped 
to a HOL term that represents a simplified process. 



Mapping Models. For a given mRSL signature 27, /3s maps HOL Sig(g(I 7))- 
models into mRSL 27-models. 

The definition of f3s is based on a function B that maps mRSL types (value 
domains) to sets in U and a function D that maps values to elements of sets in 
'll, i.e., 

B : Types ► 'll and D : type ► B(type) for type £ Types. 

The functions B and D are injective and define a standard encoding of mRSL 
types in HOL. B _1 and D -1 denotes the left inverses of B and D, respectively. 

Let 27 = (S,A,<P,V) be an mRSL signature, and let m = {mo, me) be a 
Sig(p(27))-model with standard encoding of mRSL types so that (1) for all s € S 
there exists a type t such that mn(s , 0) = B(t) and (2) for all v £ V t there exists 
an element dv of the type denoted by t' such that )) = D{dv). Then 

/3s(m) is defined as (ms,mA,mv) where 

- ms{s) = B~ 1 (ma(s, 0)) for s £ S 

- mA is defined by ms and F, as usual 

- rn v = (m Vt : V t m r( s)(f)) tG T(S), where m Vt {c ) = D~ 1 (m c {c T )) for 

c £ V t , t £ T(S), and r = A^ft). 

Proposition 1. For all mRSL signatures 27, mRSL 27 -value expressions ve, 
and HOL Sig(g(E)) -models m, if f3s{m) is defined, then 

D(Ms{/3s(m))(ve)) = [A s { ve)\ m . 

Proof. By induction on the structure of ve. See [10] for details. 

Proposition 2. (g,a,/3) : Im.RSL ► Ihol is a light institution comorphism. 

Proof. It should be shown that 

m |= Sig( e (i:)) us{v) iff P s(m) \=s T 

for all mRSL signatures 27, mRSL 27-sentences ip, and HOL p(27)-models m for 
which /3s(iti) is defined. This follows from the definition of b Sig(e(s))i Prop. 1, 
the definition of as, injectivity of the function D , and the definition of bu- 



Proposition 3. /3s is surjective for 27 £ \Sign m iisL\- 
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Proof. For each signature E = (S, A,\L,V) and mRSL A-model m = (ms, 
rriA, my) there is a HOL S'ig(p(Z’))-model m! = (m' Q , m ! c ) such that m' Q (s, 0) = 
B(ms(s)) for s £ S and m' c (c r ) = D(iny(c )) for c in V. Since f3s(m!) = m, the 
mapping f3s is surjective. 

By Prop. 3, Theorem 1, and soundness of Isabelle/HOL, we can use the light 
institution comorplrism to translate mRSL specifications and proof obligations 
to HOL and reuse Isabelle/HOL as illustrated below: 

mRSL HOL 



SPmRSL b PmRSL SPrOL \= PHOL 

Isabelle 

SPmRSL b PmRSL — : — Yes 

Reusing Iheorem 

5.2 Translating mRSL Specifications 

We now describe how the light institution comorphism (g, a, 0) provides a trans- 
lation of mRSL specifications to Isabelle/HOL theories. 

An Isabelle/HOL theory, mRSL, is constructed to represent the fixed con- 
tribution ((L2mRSL,CmRSL) , E m RSL) of definitions of data types and constants 
needed for expressing the mRSL semantics in HOL. 

Consider an mRSL specification SP representing an mRSL signature E and a 
set E of mRSL sentences, and let ((f2 m RSL OQr, C m RSL^Cs), E m RSL) = g(E) 
and let E ' = ole(E). The specification SP is translated to an Isabelle/HOL 
theory which extends mRSL with (1) declarations that represent Qr and Cs and 
(2) the axioms in E' . 

More precisely: 

— sort declarations type s are translated to typedecl s, 

— abbreviation type declarations type T = type^expr are translated to 
type s = r, where r = A^ftype-expr), 

— value declarations value v : type^expr are translated to 
const s v : : "r", where r = A^ftypejexpr ) , and 

— axiom declarations axiom [id\ ve\ = ve 2 are translated to 
axioms id : "vei = ve 2 M , where ve* = Asivef) 

The translation may be described as a shallow embedding encoding the se- 
mantics. It is shallow since we use data types that are part of Isabelle/HOL 
rather than axiomatizing the data types from mRSL. Moreover, it encodes the 
semantics since the translation of sentences (from axioms) is based on the deno- 
tational semantics. 

Example. As an example, we here show the result of translating the specifica- 
tion from Sec. 3.1 to an Isabelle/HOL theory: 
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theory GAS = mRSL : 
typedecl State 

consts gas :: "State => (bool P) " 

flame :: "State => (bool P) " 
leak :: "State => (bool P) " 
axioms leak_def : 

"((Proc leak)) = (v2p ("/, s :: State . ((appl (Proc gas) (Proc s)) 

AND (NOT (appl (Proc flame) (Proc s))))))" 
axioms gas_total : 

" (v2p (ALL s . ( (v2p (EX b . ((appl (Proc gas) (Proc s) =rsl 
(Proc b) ) = true))) = true))) = true" 
axioms flame_total : 

" (v2p (ALL s . ( (v2p (EX b . ((appl (Proc flame) (Proc s) =rsl 
(Proc b) ) = true))) = true))) = true" 
end 

where v2p lifts values to processes, appl expresses function application, and AND 
and NOT express the connectives A and ~. 

We can prove that the specification has the following property: 

(V s : State flame(s) => ~leak(s)) 

expressed by the following lemma in Isabelle/HOL: 

lemma f lame_no_leak : 

" (v2p (ALL s :: State . ((appl (Proc flame) (Proc s)) 

IMP (NOT (appl (Proc leak) (Proc s)))) = true)) = true" 

5.3 Case Studies 

Case studies concerning use of the light institution comorphism to provide in- 
creased proof support are described in [10]; they include logic circuits, a gener- 
alized railway crossing, and an encoding of Duration Calculus. The translation 
and reuse of Isabelle provided increased proof support in most cases. 

Also a series of RSL proof rules has been translated to Isabelle/HOL and 
proved as theorems using Isabelle. This not only provides helpful theorems but 
also formally proves the RSL proof rules sound with respect to the denotational 
semantics. So far, only a simplified semantics for a subset of RSL is considered, 
but a formal proof relating the proof rules and semantics is novel work. 

6 Conclusion 

In this section we summarize achievements, related work and future work. 

6.1 Achievements 

The major contribution of the work reported in this paper is the provision of 
proof support for an applicative subset, mRSL, of RSL in the form of a transla- 
tion from this subset into Isabelle/HOL. We choose an applicative subset, since 
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according to the RAISE method most proofs are done for applicative specifica- 
tions. Case studies have shown that this proof support has a higher degree of 
automation than the original RAISE proof tools. 

In order to make the translation sound (so that Isabelle/HOL proofs made 
for translated mRSL proof obligations are sound wrt. the mRSL semantics) we 
took the following approach: First we formulated an institution for the considered 
subset of RSL and gave an institution-independent semantics of the subset. Then 
we defined a light institution comorphism from the mRSL institution into an 
institution for HOL and proved that this fulfills a condition that ensures the 
desired soundness properties. 

The presented institution and semantics for mRSL not only provide the foun- 
dations for providing proof support, but are also new, interesting results on 
their own. Institutions have typically been defined for algebraic specification 
languages, while our institution is defined for a language that combines features 
from algebraic specification and model-oriented specification. Compared with 
the original semantics of RSL, our new semantics is more elegant and easy to 
understand as simpler semantic domains are used (this is possible as we only 
consider a subset of the full language) and a clear structure is provided by the 
institutional setting. Moreover, an advantage of defining the semantics in an 
institutional way is the institution-independent results that then come for free. 



6.2 Related Work 

The RAISE tool suite developed at UNU/IIST [7] provides a translator from 
another applicative subset of RSL to PVS so that the PVS theorem prover can 
be reused. This subset does not include partial functions, but on the other hand 
provides more type constructors. The translation is not based on institutions 
and has not been proved sound. 

Other kinds of institution comorphisms have been used to provide proof 
support for other languages than RSL, e.g., the algebraic specification language 
CASL [3,11]. 

6.3 Future Work 

We plan to extend the subset with more type constructors and subtypes to 
make the applicative subset more complete. This can easily be done within the 
framework we have set up. It should also be considered to which extent the 
module structuring operations can be included. 
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Abstract. We present a separate compositional analysis for object- 
oriented languages. We show how a generic static analysis of a context 
that uses an object can be split into two separate semantic functions 
involving respectively only the context and the object. The fundamental 
idea is to use a regular expressions for approximating the interactions 
between the context and the object. Then, we introduce an iterative 
schema for composing the two semantic functions. A first advantage is 
that the analysis can be parallelized, with a consequent gain in mem- 
ory and time. Furthermore, the iteration process returns at each step 
an upper approximation of the concrete semantics, so that the iterations 
can be stopped as soon as the desired degree of precision is reached. 
Finally, we instantiate our approach to a core object-oriented language 
with aliasing. 



1 Introduction 

One important facet of object-oriented design is encapsulation. Encapsulation 
hides the objects’ inner details from the outside world and allows a hierarchical 
structuring of code. As a consequence, a program written in the object-oriented 
style has often the structure of C[o], where C[-] is a context which interacts with 
an encapsulated object o. The interaction between the context and the object 
can be of two kinds. The first, direct, one is through method invocations. The 
context invokes a method of the object which may return some value and modify 
its internal state. In particular, the value returned by the method can be a pointer 
to the value of a field. Thus, the object may expose a part of its internal state 
to the context, which can arbitrarily change the value of the field. We call this 
second kind of interaction an indirect one. 

We are interested in an analysis that exploits the encapsulation features of the 
object-oriented languages, so that the context and the object can be analyzed 
separately. In fact, most available analyses are not separated e.g. [7], or they 
are imprecise as they assume the worst case for the calling context, e.g. [8]. A 
separate analysis presents several advantages. First, it may significantly reduce 
the overall analysis cost both in time and space, as e.g. different computers can be 
used for the analysis of the context and the object. Second, as the total memory 
consumption is reduced, very precise analyses can be used for the context and/or 
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the object. Third, it allows a form of modular analysis: if o is replaced by another 
object o' then the analysis of C[o'] requires just the analysis of o'. For instance, 
this is the case when C[-] is a function and o and o' are actual parameters, or 
when o' is a refinement of o, e.g. o' is a sub-object of o. 

We present a compositional separate analysis of class-based object oriented 
languages. We illustrate and prove our results for a core object-oriented language 
with aliasing. In particular in the considered language the identity of an object 
is given by the memory address where its environment is stored. This implies 
that we handle objects aliasing and that objects are semantic rather than syn- 
tactic entities. This is in line with mainstream object-oriented languages, so the 
presented framework can be easily extended to cope with realistic languages. 

In Sect. 2, we define the syntax and the concrete semantics for our language 
and in Sect. 3 we present a generic monolithic static analysis of the context 
and the object [C[o]] a , parameterized by an abstract domain D a . In Sect. 4, we 
show how it can be split into two semantic functions, T and 0 , corresponding 
respectively to the analysis of the context and the object. The fundamental idea 
is the use of regular expressions for approximating the interactions between the 
context and the object. Therefore, we refine the abstract domain D a with a 
domain of regular expressions. We have that: 

- The object analysis 0 is a function that takes as input a map from objects to 
regular expressions. It returns a map from objects to their approximations. 

- The context analysis T is a function that takes as input the approximation 
of the semantics of the objects. It returns an abstract value and a map from 
objects to regular expressions. 

The functions 0 and r are mutually recursive. Thus, we handle this situation 
with the usual iterative approach. In particular, we begin by assuming the worst- 
case for the objects approximations and the contexts. Then, we show that the 
iterations form a chain of increasing precision, each step being a sound upper- 
approximation of [C[o]] a . This implies that the iterations can be stopped as 
soon as the desired degree of precision is reached, enabling a trade-off between 
precision and cost. 



2 Concrete Semantics 

We begin by defining the syntax and the semantics of a minimal Java-like lan- 
guage. We make some simplifying assumptions. First, in order to simplify the 
notation we assume the existence of just one class. The generalization of the 
results to the case of an arbitrary number of classes is straightforward. Second, 
we distinguish between a context, for which we will give the detailed syntax, and 
a class, for which we give just the interface, i.e. the fields and the methods, but 
not the definition of the methods body. This is not restrictive, as the notion of 
context is relative. For example, a context that accesses an object o can be the 
body of a method of an object o'. Such an o' can be accessed by further context, 
so that the contexts can be encapsulated. 
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2.1 Syntax 

The class syntax can be abstractly modeled as a triplet (init, F, M) where init is 
the class constructor. F is a set of variables and M is a set of function definitions. 
We do not require to have typed fields or methods and without any loss of 
generality we assume that a class has just a single constructor and each access 
to a field f is done through set _f/get_f . 

The syntax of a context is quite standard, except that we distinguish three 
kinds of assignments: the assignment of the value of a side-effects free expression 
to a variable, the assignment of the address pointed by a variable to another one 
and the assignment of the return value of a method call to a variable. So, let x, 
xi, X 2 and o be variables, let E be an expression and let b be a boolean expression. 
Then the language of contexts is generated by the following grammar: 

C ::= A o = new A(E) | Ch; C 2 | skip | x = E | xi = x 2 
| x = o.m(E) j if b then Ci else C 2 | while b do C. 

C denotes an arbitrary context, C [-] denotes a context that may contain one or 
more objects and C[o] denotes a context that uses an object o. However, as we 
allow aliasing of objects, we cannot give the formal definition of C[o] on a strictly 
syntactic basis. Therefore, such a definition is postponed to the next section. 

2.2 Semantic Domains 

The first step for the specification of the concrete semantics is the definition of 
the concrete domain. In our case, we are interested in a domain that models 
the fact that an object has its own identity and environment. Moreover, we 
need to express object aliasing. In order to fulfill the above requirements, we 
consider a domain whose elements are pairs of environments and stores. An 
environment is a map from variables to memory addresses, Env = [Var — > Addr], 
and a store is a map from addresses to memory elements, Store = [Addr — > Val], 
A memory element can be a primitive value as well as an environment or an 
address, i.e. Env C Val and Addr C Val. In such a setting, the identity of an 
object is the memory address where its environment is stored. Therefore, two 
distinct variables are aliases for an object if they reference the same memory 
address. 

2.3 Object Semantics 

We consider an input/output semantics for the class constructor and the meth- 
ods. The semantics of the constructor is a function 3 [init] £ [Val x Store — ■> 
Env x Store] which takes as input the constructor’s actual parameter and a store. 
It returns the (initialized) object environment and the (possibly modified) store. 
It is worth noting that the constructor does not return any value to the context. 

The semantics of a method m is a function M[m] £ [Val x Env x Store — > 
Val x Env x Store], It takes as input the method’s actual parameter, the object 
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6 [A o = new A(E)] = Ae, s.let v = £[E](e, s), a = alloc(s), 

(e 0 , so) = 3[init](i;, s), 
in (e[o i — * u] , so [ct i — * eo]) 

e[Ci;C 2 ] = Ae, s.e[C 2 ](e[Ci](e, s)) C[skip] = Ae, s.(e, s) 

CJx = E| = Ae, s.(e, s[e(x) £[E](e,s)]) 
e[xi = x 2 ] = Ae, s.(e, s[e(xi) i-> e(x 2 )]) 

C[x = o.m(E)] = Ae, s .let v = £[E](e, s), (u 0 , eo,s 0 ) = M[m](u, s(e(o)), s), 
in (e, s 0 [e(x) i-> vo,e(o) e 0 ]) 

6 [if b then Ci else C 2 ] = Ae, s.ifU [b] (e, s) = tt then C[Ci](e,s) else C[C 2 ](e, s) 
C[while b do C] = lfpA<^.Ae, s.i/23[b](e, s) = tt then </>(C[C](e, s)) else (e, s) 

Fig. 1. Semantics of the context 



environment and the store. It returns a (possibly void) value, the new object 
environment and the modified store. It is worth noting that as Ad dr C Va I the 
method may expose a part of the object’s internal state to the context. 



2.4 Context Semantics 

We define the context semantics in denotational style, by induction on the 
syntax. The semantics of expressions and that of the boolean expressions are 
assumed to be side-effect free, such that £[e] G [Env x Store — » Va I] and 
23 [b] G [Env x Store — » {tt, ff }] . A function alloc G [Store — > Addr] returns a fresh 
memory address. The semantics of a context, C[C] G [Env x Store — ■> Env x Store] 
is given in Fig. 1. 

Some comments on the context semantics. When a class A is instantiated, 
the initial value is evaluated, and the class constructor is invoked with that value 
and the store. The class constructor returns the environment eo of the new object 
and the modified store s 0 . Then the environment and the store change, so that o 
points to the memory allocated for storing e 0 . When a method of the object o is 
invoked, its environment is fetched from the memory and passed to the method. 
This implies that the method has no access to the caller environment, but only 
to that of the object it belongs to. In other words, the context has the burden of 
setting the right environment for a method call, so that the handling of this is 
somehow transparent to the callee. For the rest, the semantics in Fig. 1 is a quite 
standard denotational semantics. In particular, the loop semantics is handled by 
the least fixpoint operator on the flat Scott-domain Env x Store U {T}. 

Using the context semantics, we can formally define the writing C[o], i.e. 
the context C[-[ that uses an object o. Let (eo,So) G Env x Store, such that 
C[C](e 0 ,So) = (e,s). Then a context C uses an object o if 3x G Var.e(x) = 
o A s(e(x)) G Env. 
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2.5 Collecting Semantics 

A semantic property is a set of possible semantics of a program. The set of seman- 
tic properties T(Env x Store) is a complete boolean lattice (3 3 (Env x Store) ,C,0, 
Env x Store, U,n) for subset inclusion, that is logical implication. The standard 
collecting semantics of a program, |C](/n) = {C[C](e, s) | (e,s) £ In}, is the 
strongest program property. The goal of a static analysis is to find a computable 
approximation of [C] . 

3 Monolithic Abstract Semantics 

We proceed to the definition of a generic abstract semantics for the language 
presented in the previous section. First we consider the abstract semantic do- 
mains. Afterward, we present the abstract semantics for the class constructor 
and methods, and for the context. 



3.1 Abstract Semantic Domains 



The values in T(Val) are approximated by an abstract domain Val a . The corre- 
spondence between the two domains is given by the Galois connection [2] : 



(J’(Val), C, 0, Val,U, fl) 



(Val^a^T^u:,,^). 



The set of abstract addresses is Addr a C Val a . We assume Addr a to be a sublattice 
of Val a . If o e Addr denotes an object in the concrete, then D = a„({o}) is 
the corresponding abstract address. On the other hand, D stands for the set 
of concrete addresses (■$), which may contain several objects. Therefore, d 
approximates all the objects in 7„($). We call d an abstract object. 

The domain D a abstracts the domain of concrete properties T(Env x Store) 
by means of a Galois connection: 

(jP(Env x Store), C, 0, Env x Store, U, fl) < - ~ 7 . > (D a , C a , _L a , T a , U a , n a ). 

We call an element of D a an abstract state. In general, the domain D a is a 
relational abstraction of T(Env x Store). We consider two projections such that 
for each d a £ D a , d a |_ e and d a ) s are, respectively, the projections of d a on 
the environment and the store. We use the brackets |_’J to denote the inverse 
operation of the projection, i.e. given an abstraction for the environment and 
the store it returns the abstract state. Moreover, some operations are defined 
on D a : alloc 3 , assign 3 , true 3 and false 3 . The first one, alloc 3 £ [D 3 — > Addr 3 ], is 
the abstract counterpart for memory allocation. It takes an approximation of 
the state and it returns an abstract address where the object environment can 
be stored. It satisfies the soundness requirement: Vd a £ D a .{alloc(s) | (e,s) £ 
7(d a )} C 7 „(alloc a (d a )). 

The function assign 3 £ [D a x (Varx D 3 ) + — > D 3 ] handles the assignment in the 
abstract domain. It takes as input an abstract state and a non-empty list of bind- 
ings from variables to values. It returns the new abstract state. With an abuse 
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of notation, we sometimes write assign 3 (d a , d 3 | s i— > dp | s ) to denote that the ab- 
stract store d a | s is updated by dp ts. Moreover, true 3 , false 3 € [BExp xD’-» D a ] 
are the functions that given a boolean expression and an abstract element d a 
return an abstraction of the pairs (e, s) £ 7(d a ) that make the condition respec- 
tively true or false. For instance true 3 is such that: 

Vb € BExp.Vd 3 € D 3 .{(e, s) | ®[b](e, s) = tt} fl y(d a ) C true a (b, d a ). 

3.2 Abstract Object Semantics 

The abstract semantics for the class constructor and methods mimics the con- 
crete one. Therefore, the abstract counterpart for the constructor semantics is 
a function U[init] a £ [Val 3 x D a — > D a ], which takes an abstract value and 
an abstract state and returns an abstract environment, that of the new ob- 
ject, and an abstract store. The abstract semantics for methods is a function 
M[m] a £ [Val 3 x D a — > Val 3 x D 3 ]. The input is an abstract value and an ab- 
stract state, and the output is an abstraction of the return value and a modified 
abstract state. 

3.3 Monolithic Abstract Context Semantics 

The abstract semantics for contexts is defined on the top of the abstract se- 
mantics for the expressions and the basic operations of the abstract domain 
D 3 . In particular, the abstract semantics of expressions is £[e] a £ [D a — » Val 3 ]. 
It must satisfy the soundness requirement: V(e, s) £ Env x Store. 8 lei (e, s') £ 
Tv o £|e] 3 oa({(e,s)}). 

The generic abstract semantics mimics the concrete semantics. In particular, 
when a method m is invoked, the corresponding abstract function M|m] 3 is used. 
In practice, this means that the body of a method m is analyzed from scratch 
at each invocation. Therefore the encapsulation of the object w.r.t. context is 
not exploited in the analysis. We call such an abstract semantics a monolithic 
abstract semantics in order to differentiate it from the separate compositional 
abstract semantics that we will introduce in the next section. 

Finally, the monolithic abstract context semantics [C] a £ [D a — ► D a ] is de- 
fined in Fig. 2. The semantics in Fig. 2 is quite similar to the concrete one in 
Fig. 1. It is worth noting that the burden of handling the assignment is left to 
the underlying abstract domain D a , and in particular to the function assign 3 . We 
use the notation lfpjAx.E(a:, z) to denote the least fixpoint w.r.t. the order C, 
greater than d of the equation F(x, z) = ( x , y), for some z and y. Nevertheless, in 
general the abstract domains Val 3 and D a may not respect the Ascending Chain 
Condition (ACC), so that the convergence of the analysis is enforced through 
the widening operators V 3 £ [Val 3 x Val 3 — > Val 3 ] and V 3 £ [D 3 x D a — » D 3 ]. 
The soundness of the above semantics is a consequence of the definitions of this 
section: 

Theorem 1 (Soundness of [C] 3 ). The monolithic context abstract seman- 
tics is a sound approximation of the concrete semantics: Win € T(Env x Store). 
|C](/n) C 70 [C] 3 ou(In). 
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[A o = new A(E)] a = Ad 3 .let v a = £ [E] a (d a ), i? = alloc a (d a ), 
do a = 3[init] a (v a ,d a ) 
in assign a (d a , i? d 0 a U, d a [ s i-+ d 0 a U) 

[Ci; C 2 f = Ad a .[C 2 ] a ([Cif(d a )) [skip] 3 = Ad a .d a 
[x = E] a = Ad a .assign a (d a , x i— > £[E] a (d 3 )) 

[xi = x 2 ] a = Ad a .assign a (d a ,xi i-» d a U(x 2 )) 

[x = o.m(E)] a = Ad 3 .let v a = £|E] a (d a ),i? = d a U(°)> 

(v 0 3 ,do a ) = M[m] a (v a , [d a U(r?),d a UJ), 
in assign 3 (d a ,x i— > v 0 a ,$ d 0 a U,d a Ls 1 — ^ d 0 a U) 

[if b then Ci else C 2 ] a = Ad a .[C 1 ] a (true a (b, d a ))U a [C 2 ] a (false a (b, d 3 )) 



[while b do C] a = Ad 3 .false 3 (b, lfp|p Ax.[C] a (true a (b, x))) 



Fig. 2. Monolithic abstract semantics 



4 Separate Abstract Semantics 

The abstract semantics |-] a defined in the previous section does not take into 
account the encapsulation features of object-oriented languages, so that, for in- 
stance each time a method of an object is invoked, its body must be analyzed. 
In this section we show how to split [-] a into two parts. The first part analyzes 
the context using an approximation of the object. The latter analyzes the object 
using an approximation of the context. 

4.1 Regular Expressions Domain 

The main idea for the separate analysis is to refine the abstract domain D a 
with the abstract domain R of regular expressions over the infinite alphabet 
({init}U?(M)) x Val a x D a . Given an object, the intuition behind the refinement 
is to use a regular expression to abstract the method’s invocations performed 
by the context. In particular, each letter in the alphabet represents a set of 
methods that can be invoked, an approximation of their input values and an 
approximation of the state. Such a regular expression is built during the analysis 
of the context. Then it is used for the analysis of the object. 

The definition of the regular expressions in R is given by structural induc- 
tion. The base cases are the null string e and the letters l of the alphabet 
({init} U T(M)) x Val a x D a . Then, if 77 and r 2 are regular expressions so are 
the concatenation n • r 2 , the union r\ + V 2 and the Kleene-closure r\. 

The language generated by a regular expression r is defined by structural 
induction: 

£((ms, v a ,s a )) = {(m, v, s) | m € ms, v G 7„(v a ), s G 7 (s a )} £(s) = 0 

£(ri • r 2 ) = {si • s 2 | si G £(r*i), s 2 G £(r 2 )} L(n + r 2 ) = £(r i) U £(r 2 ) 
L(r*) = lfp^A X.L(r) U {si • s 2 | si G X, s 2 G £(r)}. 
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r VrX — rVrTr — T r X V r c 

(m, v a ,s a )Vr(mi,Vi,Si) = (m U nu, v a V a v a , s a V a sj) (ri • r2)V r n 

(ri + r2)V r n = (nV r n) + (r2V r n) r*V r n 

(ri ■ r 2 )V r (ri • ri) = (nV r ri) • (r 2 V r ri) rjV r ri 

(ri + r 2 )V r (rj + ri) = (riV r rj) + ( r 2 V r ri ) 

xS7 r y = T r in all the other cases 



eVr* = a: 
(riVrn) ■ r 2 
(rV r n)* 
(riV r r 2 )* 



Fig. 3. Widening on regular expressions 



The order on regular expressions is a direct consequence of the above defini- 
tion: Vr i,r 2 € R.ri C r r 2 4=> £(?r) C £(r 2 ). So, two expressions are equivalent 
if they generate the same language: rr = r 2 4=4- £( 7 * 1 ) = £(r 2 ). From now on, 
we consider all the operations and definitions on regular expressions modulo the 
equivalence =. The expression T r = ({init} U M, T a , T a )* £ R stands for a con- 
text that may invoke any method, with any input value and with any memory 
configuration for a non-specified number of times. So, it gives no information. 
Thus, it is the largest element of (R, C r ). The join of two regular expressions is 
simply their union: Wi,r 2 £ R.ri U r r 2 = r\ + r%. Similarly, the meet operator 
n r can be defined, so that (R, C r , e, T r , U r , n r ) is a complete lattice. 

The domain R does not satisfy the ACC, so we define the widening operator 
of Fig. 3 to deal with strictly increasing chains of regular expressions. There are 
two intuitions behind the operator in Fig. 3. The first one is to preserve the 
syntactic structure of the regular expressions between two successive iterations, 
so that the number of {•,+,* } does not increase. The second one is to propagate 
the V r inside the regular expressions in order to use the widenings on Val a and 
D a . Convergence is assured as M is a finite set, and V a and V a are widenings on 
the respective domains. 

For the purpose of our analysis, we need to associate with each abstract ad- 
dress, i.e. a set of concrete objects, a regular expression that denotes the inter- 
action of the context on it. As a consequence we consider the functional lifting 1 
R = [Addr a — > R], The order C r is defined pointwise: Vr'i,r '2 € R.r'i fcyr '2 <t=> 
Vi 9 £ Addr a .r'i(-d) r' 2 (i?). In a similar way, the join and the meet are defined 

point-wise, so that (R, C r , Ad.e, Ad.T r , U r , fj r ) is a complete lattice. We call an 
element f £ R an interaction history. 



4.2 Separate Object Analysis 

The goal of the separate object analysis is to infer an object invariant and the 
method postconditions when the instantiation context is approximated by a 
regular expression. Thus, the input of the abstract semantics 0[d] a is a regular 

1 We use the notation that given a domain D a , D a stands for the domain of functions 
[Addr a — > D a ]. The operations on D a are the pointwise extension of that of D a : given 
an operation o, then Vdj,d| £ D a . dj <> d| = AV.dj(V) o d|(V). 




342 Francesco Logozzo 



0M a ( £ , (i a , P a » =(i a , P a > 

OM a ({{init }, v a ,s a ), (i a , p a » =let (eg, Sq) = JJinitf (v a , s a U a i a ) 

in (i a U a Sg, p a [init (± a ,ej()]} 

OM a ((ms,v a ,s a ),(i a ,p a » =let Vmi ems.(v a ,s a ) = M[ mi ] a (v a , s a U a i a ), <w a ,q a > = p a ( mi ) 
in (i a U a U a sf,p a [m ± h- <w a U a v a ,q a U a s a >]) 

0[i?] a ( ri • r 2 , (i a , p a >| =let (if.pf) = 0[i?] a (n, (i a , p a >), (i 2 , p 2 ) = Ol^Cra, (i!,p!)) 
in (i a ,p a )U a (i a 1 ,p a 1 )U a (i a 2 ,p|) 

OM a (n +r 2 ,(i a ,p a » =let (ij.pt) = 0[tf] a (n, (i a , p a », (i|,p|) = 0[i?] a (r 2 ,(i a ,p a » 
in (i a , p a )U a (ij, pj)U a (i|, p|) 

OM a (r*,(i a ,p a » =lfp^a°pa) Ax,2/.0[i?] a (r, (x,y)) 

Fig. 4. Separate object abstract semantics 



expression r and an initial abstract value for the object fields and the method 
preconditions. The output is an invariant for the object fields and the method 
postconditions, under the context represented by r. A postcondition is a pair 
consisting of an approximation of the return value and an abstract state. Thus, 
the result is an element of the abstract domain 0 a = D a x[M— > Val a x D a ]. From 
basic domain theory, the orders on D a and Val a induce the order on 0 a . So, the 
order is C a = C a x (C a xC 3 ), the least element is _L a = (_L a , Am.(_L a , _L a )) and 
the largest T a = (T a , Am.(T a , T a )). The meet, the join and the widening can be 
defined in a similar fashion, so that (0 a , C a , _L a , T a , U a , n a ) is a complete lattice. 
Finally, the separate object abstract semantics, 0[d] a e [RxO a ^ 0 a ], is defined 
in Fig. 4. Its definition is by structural induction on the regular expression r. 

Some comments on the separate object semantics. The base cases are the 
empty expression £ and the letters (ms,v a ,s a ) and ({init}, v a , s a ). In the first 
case the context does not perform any action, so that the state of the object does 
not change at all. In the latter, the context may invoke any method mi £ ms. The 

abstract value | | a S| a approximates the object field values after calling the method 

mi or m 2 or .. . or m n . As a consequence, i a U a |_| a s; a approximates the object fields 
before and after executing any method in ms. Hence, it is an object invariant. On 
the other hand, if (w a ,q|) is the initial approximation of the return values and 
the states reached after the execution of a method mi £ ms, then (w a Ll a v a , q a U a s a ) 
is the postcondition of mi after its execution. The case of the constructor init 
is quite similar. 

As for the inductive cases are concerned, the rules for concatenation and 
union formalize respectively that “the context first performs rq and then r 2 ” 
and “the context can perform either r\ or r 2 ”. Finally, the rule for the Kleene- 
closure is a little bit more tricky. In fact the intuitive meaning of r* is that, 
starting from an initial abstract value (i a , p a ) the context performs the interaction 
encoded by r an unspecified number of times. We handle this case by considering 
the least fixpoint greater than (i a ,p a ) according to the order C a on 0 a . If the 
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abstract domains D a and Val a do not respect the ACC then the convergence of 
the iterations must be enforced using the following pointwise widening operator: 



A(i a ,p a ),(r,p' d ).(i a V a r,Am.p a (m) (V a „ x V a ) p' d (m)). 



The regular expression ry = ({init}, T a , T a ) • T r stands for a context that 
calls at first the class constructor with an unknown value and then may invoke 
any object method, with any possible value, an unspecified number of times. 
Thus the abstract value (i a , p a ) = 0[d] a (rT, T a ) is such that i a is a property of 
the object fields valid for all the object instances, in any context. So it is a class 
invariant in the sense of [5,4]. In the following we refer to it as [A] a . 



4.3 Separate Context Analysis 

The separate context analysis C[C[-]] a has two goals. The first goal is to analyze 
C[o] without referring to the o code, but just to a pre-computed approximation 
of its semantics. The second goal is to infer, for each object o a regular expres- 
sion r that describes the interaction of the context with o. This r can then be 
used to refine the approximation of the object semantics. In general, a context 
creates several objects and it interacts with each of them in a different way. As 
a consequence, in the definition of the abstract context semantics 6[-] a we use a 
domain 0 a = [Addr a — > 0 a ], whose elements are maps from abstract objects to 
their approximations. The definition of C[C] a £ [D a x 0 a x R — * D a x R] is given 
by structural induction on C in Fig. 5. 

Some comments on the separate context semantics. The semantics takes 
three parameters: an abstract state, an approximation of the semantics of the 
objects and the invocation history. When a class is instantiated, the semantics 
C[-] a (abstractly) evaluates the value to pass to the constructor init and it 
obtains an address •& for the new object. Then, it uses the object abstraction 
i?($) to get the constructor postcondition p a (init) and it updates the invoca- 
tion history. In general, the abstract address i? identifies a set J v (i9) of concrete 
objects. So, the semantics adds an entry to the i9 history corresponding to the 
invocation of init, with an input v a and an abstract state d a . Eventually, the 
result is the new abstract state, obtained considering the store after the execu- 
tion of the constructor, and the updated invocation history. The sequence, the 
skip and the two assignments do not interact with objects so, in these cases, 
C[-] a is very close to the corresponding semantics of Fig. 2. The definition of 
C[-] a for method invocation is similar to the constructor’s one: it fetches the 
(abstract) address corresponding to o and the corresponding invariant. Then, it 
updates the abstract state, using the m postcondition, and the invocation history. 
The definition of the conditional merges the abstract states and the invocation 
histories originating from the two branches. Eventually, the loop is handled by 
the least fixpoint operator on the abstract domain D a x R. In particular we 
consider the least fixpoint greater than (d a , AzA e) as we need to compute an in- 
vocation history that is valid for all the iterations of the loop body. The history 
for the whole while command is the concatenation of the input history with 
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C[A o = new A(e)] a = Ad a , r.let v a = £[e] a d a ,$ = alloc 3 (d a ), 

(i a > P a > = ^($)> (-L* , dg> = p a (init), 
r' = r [$ i— » ({init}, v a , d a ) U,. f ($)] 
in (assign 3 (d a , i? i— > dg Le,d a [, s i — s- dg U),r') 

e[Ci;C 2 ] a = Ad a ,i l r.let (df,ri) = e[Ci] a (d a , tf,r) 
in e[C 2 ] a (di,)?,r-i) 

C[skip] a = Ad a , ij, f.(d a , r) 

C[x =e] a = Ad 3 , i 9 , r.(assign 3 (d 3 , x i— > £[e] 3 (d 3 )), r) 

C[xi = x 2 ] a = Ad a ,i?,r.(assign a (d a ,xi i-> d a U( x 2)),f) 

C[x = o.m(e)] a = Ad a , i 9 , r.let v a = £[ej 3 (d 3 ), i? = d a U(°); 

(i a ,p a >=^),(v^q:> = p a (m) 

d' a = assign 3 (d a , x i— » v 3 ,tf i-* q 3 U.d 3 (s >-* Ls), 

in (d' a , r[i? i— > r( i?) • (m, v a , [d 3 U (i?) , d a UJ }] ) 

C[if b then Ci else C 2 ] a = Ad 3 ,i i, r.let (d|,fi) = C[Ci| a (true a (b, d a ), i), f), 

(d^ , 7^2) = C[C 2 ] a (false 3 (b, d a ), i), r) 
in (df U a d|, fiU r r2) 

CJwhile b do C] a = Ad 3 , 1?, r.let (d ,a , r') = lfp^ a ^^ r £ j A(a;, ?/).C[C] 3 (true 3 (b, x),i 9 , y) 
in (false 3 (b, d ,a ), Ai?.r ($) • (r 1 ($))* ) 

Fig. 5. Separate context semantics 



the body one, repeated an unspecified number of times. As usual, the conver- 
gence of the analysis can be forced through the use of the widening operator 
A(df,fi).(d|,r 2 ), (dfV a d|,fiV r f 2 ). 

We conclude this section with two soundness lemmata. The proof for both 
can be found in [6]. The first one states that for each initial value and ob- 
ject approximation, all the history traces computed by C[-] a are of the form of 
({init}, v a , s a ) • r, for some v a £ Val a ,s a £ D a and regular expression r. Intu- 
itively, it means that the first interaction of the context with an object is the 
invocation of init with some value and store configuration. This fact can be 
used to show that [A] a , as defined in the previous section, overapproximates the 
semantics of all the objects. Thus, that it is a sound class invariant. 

Lemma 1 (Soundness of the class invariant). Let dj} £ D a , 1 ? £ 0 a and 

C[C] a (dQ, •&, Xd.e) = (d a ,r). Then for all the abstract objects d such that rfd) 7^ e: 

(i) f(’d) = ({init), v a , s a ) • r, for some v a £ Val a , s a £ D a and r £ R: 

(ii) O[0] a (f(0),lo) E a [A] a . ’ 

The next lemma shows that the history traces computed by C[-] a are an 
overapproximation of the history traces computed by [-] a . Thus, the soundness 
of [•] implies that the history traces are a sound approximation of the context. 
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Lemma 2 (Soundness of the history traces). Let |C[o]] a (_L a ) = d a , a„({o}) 
= d and t = (init, v a , s a ) • (mi, v a , sf) . . . (m„, v a , s a ) a sequence of method invo- 
cations of d when the rules of Fig. 2 are used to derive d a . Then C[C[o]] a (_L a , 
Ai9.|[A] a , = (d ,a ,r') is such that d a C a d' a and L(t) C £(r' (■$)). 



4.4 Putting It All Together 



In this section we show how to combine the two abstract semantic functions 
0[-] a and C[-] a in order to obtain a separate compositional analysis of C[o]. The 
functions 0[-] a and C[-] a are mutually related. The first one takes as input an 
approximation of the context and it returns an approximation of the object 
semantics. The second one takes as input an approximation of the objects. It 
returns an abstract state and, for each abstract object d, an approximation 
of the context that interacts with d. Then it is natural to handle this mutual 
dependence with a hxpoint operator. 

Nevertheless, before doing it we need to define formally the function 0 £ 
[R — > O a ], that maps an interaction history f to a function d from abstract objects 
to their approximation. First we consider the set of the abstract objects that 
interact with the context, i.e. the abstract addresses whom interaction history is 
non-empty: I = {$ | r( d) f e}. Next, we define a function that maps elements 
of / to their abstract semantics and the others to the class invariant [A] a : 



&r = Xd. 



OH a (r(tf),T a ) 

[Af 



if t?e I 
otherwise. 



(1) 



Moreover, we require that the more precise the abstract object, the more precise 
its abstract semantics. Therefore we perform the downward closure of dr, to 
make it monotonic. Finally, the object abstractions function in a context r, 
0 £ [R — ■> 0 a ], is defined as 0(r) = At?. n a {-dj.($') | d' € Addr a and d The 

function 0 is well-defined as Addr a is a sublattice of Val a and the monotonicity 
of 0(f) is a direct consequence of the definition. 

Using the above definition and defining r(d) = C[C] a (_L a , d, Xd.e), it is now 
possible to formally state the interdependence between the context and the ob- 
jects semantics as follows: 



•d = 0(r) 

(d a ,r) = r(d). 



(2) 



A solution to the recursive equation (2) can be found with the standard iterative 
techniques. Nevertheless, our goal is to parallelize the iterative computation 
of 0 and r, in order to speed up the whole analysis. Therefore, we start the 
iterations by considering a worst-case approximation for r and d: fo = Athr-r and 
d o = AtbT a . In other words, we assume an unknown context when computing 
the abstract object semantics and an unknown semantics when analyzing the 
context. Then we obtain d i = 0(rf) and (df,ri) = r(d 0 ). 
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As we consider the worst-case approximation for the objects semantics, the 
abstract state d a is an upper approximation of [C] a (_L a ). Furthermore, it is easy 
to see that f'i t r f‘o and Roughly speaking, this means that after one 

iteration we have a better approximation of the context and the object semantics. 
As a consequence, if we compute $2 = 0(ri) and (d|,r2) = -T($i), we obtain 
a better approximation for the abstract state, the semantics of the objects and 
that of the context. This process can be iterated, so that at step i + lwe have: 

tfi+i = Gin) , 3 . 

(df +1 ,f i+1 ) = 

The next theorem synthesizes what has been said so far. It states that the 
iterations of (3) form a decreasing chain and that at each iteration step d a +1 
is an sound approximation of the monolithic abstract semantics. Hence, of the 
concrete semantics: 

Theorem 2 (Soundness). Let C be a context. Then V* > 0. 

(i) d- +1 E a df, h+iQrfi and •di+iQo'&i. 

(ii) [C] a (_L a )C a d a . 

Roughly speaking the first point of the theorem states that the more the 
iterations the more precise the result of the analysis. On the other hand, the 
second point states that the abstract states are all above the result of the mono- 
lithic abstract semantics. As a consequence it is possible to stop the iterations 
at a step i, the resulting abstract state d a being a sound approximation of the 
concrete semantics. 

An analysis based on (3) has several advantages. First, it is possible to use 
the asynchronous iterations with memory [1] in order to parallelize the analysis 
of the context and the objects. Intuitively, this is a consequence of the fact that 
at each iteration, the result of 0 and T depends just on the result of the previous 
iteration. Furthermore, 0 computes the abstract semantics for several, indepen- 
dent, abstract objects (cf. (1)). Therefore, even the effective implementation of 
0 may take advantage of a further parallelization. Finally the fact that each 
iteration is a sound approximation allows a fine tuning of the trade-off preci- 
sion/cost. In particular, we can stop the iterations as soon as the desired degree 
of precision is reached. 

Example 1 . As an example, we can consider the context and the class A in Fig. 
6, where Prop is the property: (oi.a + 01.6) — (02 .a + 02.&) + (01 .y + 02 .y) > 0. 

We are interested in proving that the assert condition is never violated. In 
order to do it, we instantiate the abstract domain D a with Polylredra [3], and 
we consider the two abstract objects and $2 corresponding respectively to 01 
and 02. According to the iteration schema (3), the first step approximates the 
objects semantics with the class invariant: 0 {r o ) = Ai9.(i a , Am.p a (m)). The object 
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01 = new A(5, 10); 

02 = new A(3, 10); 
while ... do 

if Oi.get_y() + 02 .get_y() > 0 then 

01. addA(5); Oi.addB(3); 
else 

02. addA(7); 02 .addA( 1); 

{ assert(Prop) } 

(a) The context 



F : {a,b,y} 

init(a 0 , c 0 ) : a — a 0 ; b = c 0 — a 0 ; y = 0 

addA(x) :a=a + x;b = b — x;y = y+ l 
addB(x) :a=a — x;b = b + x;y = y— 1 
get_y() : return y 

(b) The class A 



Fig. 6 . Example of a context and a class 



fields invariant is i a = {a + b = c 0 } and the method postconditions are: 



finite (T a ,i a U{y = 0 }) 
a = I addA (_L a , i a U {y = y + 1}) 

| addB (_L a , i a U {y = y - 1}) 

[get-y (T a ,i a ). 



On the other hand, as far as the context analysis is concerned, we have (0, fi) = 
r($ o), where r\ is the interaction history below. For lack of space we simplify the 
structure of the interaction history by omitting the abstract state. Nevertheless, 
in the example this is not problematic, as the objects do not expose the internal 
state. 



fi 



$1 i-» ({init}, (5, 10)) • (({get_y}, 0) • ({addA}, 5) • ({addB}, 3))* 
$ 2 ({init}, (7, 10)) • (({get_y}, 0) • ({addA}, 7) • ({addA}, 1))*. 



The result of the next iteration, i), is still too imprecise for verifying the as- 
sertion, as the object fields invariant i a implies that (oi.a+oi. 6 ) — ( 02 . 0 + 02 . 6 ) = 0 , 
but nothing can be said about Oi.y+02.y. Nevertheless, the analysis of the object 
semantics under the context f\ results in a more precise approximation of the 
objects semantics. In particular, we obtain for the first object the held invariant 
\\ = i a U {0 < y < 1} and for the latter = i a U {y > 0 }. As a consequence, a 
further iteration is enough to infer that the condition Prop is verified. From Th. 
2 it follows that the result is sound, even if it is not the most precise one. In 
fact it is easy to see that a further iteration gives a more precise result, proving 
that the else branch in the conditional is never taken. Therefore that o-2-y is 
identically equal to zero. 



5 Conclusions and Future Work 

In this work we introduced a separate compositional analysis and we proved 
it correct for a small yet realistic object-oriented language. In particular we 
presented an iteration schema for the computation of the abstract semantics 
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that approximates it from above. The central idea for the parallelization is the 
use of a domain of regular expressions to encode the interactions between the 
context and the objects. 

In future work we plan to study the practical effectiveness of the presented 
technique, for example with regard to memory consumption. Moreover, it would 
be interesting to study how many iterations are needed in order to reach an ac- 
ceptable degree of precisions. As far as the theoretical point of view is concerned, 
a straightforward extension of this work is a direct handling of inheritance. Nev- 
ertheless, in our opinion the combination of the present work with modular 
techniques for the handling of inheritance presents some more challenges that 
deserve to be explored [5] . 
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Abstract. Abstract interpretation-based static analysis infers proper- 
ties from the source code of a program. When the goal is to check a tem- 
poral specification on the program, we need the analysis to be as precise 
as possible to avoid false negatives. In previous work [9], we suggested a 
method called “property checking driven analysis” to automatically use 
the specification to check during the analysis in order to refine it. How- 
ever, this approach requires to abstract domains of lower closure opera- 
tors, something which was not developed. In this paper, we describe some 
abstractions on lower closure operators developed for a small analyzer 
of temporal properties. We examine the need for weak relational ab- 
stractions, and show that using our new approach can give more precise 
results than using a traditional abstract interpretation-based analysis 
with expensive abstract domains. 



1 Introduction 

The objective of static program analysis is to automatically infer run-time prop- 
erties on programs at compile-time. Since the properties are often undecidable, 
static program analysis uses approximations. The acceptable level of approx- 
imation depends on the application of the static analyzer: for example, when 
the goal is to remove unnecessary run-time checks [4], missing a few possible 
optimizations is acceptable. However, when the goal is to prove some specifi- 
cations about the program (e.g. the absence of run-time errors), the analysis 
must be very precise (to avoid any false negative) , and efficient enough to check 
large programs. To obtain this result, an approach is to design a special-purpose 
static program analyzer adapted to a restricted class of programs and a restricted 
class of specifications. This method was proposed and successfully applied in [1], 
for the verification of real-time embedded software. However, the analyzer so 
designed handled only one specification (the absence of run-time error) . 

It may be possible to extend the class of specifications (e.g. to a larger class 
of temporal properties) if the specification itself is used to refine the analysis. In 
previous work [9], we proposed to use the specification in a different, “reverse” 
analysis (e.g. if the abstract semantics is computed with a backward analysis, 
the “reverse” analysis is a forward one) which computes a “guide” for the com- 
putation of the abstract semantics. This approach, which we called “property 
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checking driven analysis”, uses domains of lower closure operators as the con- 
crete description of the “guide” for the main analysis. Thus, implementing this 
method requires to design efficient and precise abstractions of such domains. 

This paper extends [9] by showing how to construct such an abstract do- 
main, and presents a prototype implementation. We show different abstractions 
of domains of lower closure operators, based on the structure of the underlying 
domains. Since a non-relational domain appears insufficient to keep the precision 
of the analysis, we develop a weak relational domain for abstract environments, 
which uses a notion of local dependence between variables related to the tempo- 
ral specification. Finally we present the results of the analyzer on a few examples, 
and we discuss the merits of our approach compared with analyses using tradi- 
tional abstract domains. 

2 Concrete Semantics 

In this section, we introduce briefly the language and the kind of temporal spec- 
ifications we intend to analyse. 

2.1 Language and States 

Since the inspiration for the analyzer is Cousot’s Marktoberdorf generic ana- 
lyzer [3], we analyse roughly the same language. It is a very simple imperative 
language, with only integers and without functions. Integer values range from 
min_int to max_int, and there is an arithmetic error 12. We denote by I the 
interval [min_int,max_int], and by I ft the set IU {12}. 

The language uses arithmetic expression Aexp, boolean expression Bexp, 
command Com and list of commands Seq. The syntax is defined as: 

A £ Aexp ::= n | x | ? in [Ai,.^] | un A \ A\ bin A 2 
B £ Bexp ::= true | false | A\ = A 2 | A\ < A 2 
| B 1 andB 2 | BiorB 2 

C £ Com ::= skip | x := A | if B then S± else ^2 fi 
| while B do S od 
S £ Seq ::=C f C\ S 

Here, n are integers, x £ V variables, un £ {+, — } unary operators and bin £ 
mod} binary operators. The difference with the analyzer developed 
in [3] is the non-deterministic operation ? in [^ 1 ,^ 2 ], which returns an inte- 
ger between the value iq of A\ and the value v 2 of A 2 if Vi < v 2 , and 12 if 
V\ > v 2 . This operation intends to model all non-deterministic aspects of the 
program, e.g. user inputs, sensors or configurations. The exact meaning of each 
non-deterministic operation (i.e. how it relates to the specification) is determined 
in the temporal specification. 

Hence, a state a £ E is defined as a pair of a program point p (in a set of 
program points Lab) and an environement in V — > Ift: 

S = Lab x (V — + 1 J?) 
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2.2 Temporal Specification and Semantics 

To simplify the abstraction, we choose to analyse only simple specifications which 
make the distinction between non-deterministic operations as “internal” and “ex- 
ternal” non-determinism. These properties are expressed with /x-calculus formu- 
las of the form (we identify atomic predicates and the states they represent): 

I |= ^X(AV(5A0I)V(CAM)) 
v 

with 0 £ {p,,v}. We can note that this class of temporal specification is stable 
by negation (i.e., if (f> belongs to this class, so does -> <j>). 

Here, / are initial states, A final states, B states with “internal” non-determi- 
nism (the result of non-deterministic operations there can be chosen in order to 
satisfy the specification), and C states with “external” non-determinism (the 
specification must be satisfied for any result of the non-deterministic operations 
there). States which are not in A V B V C are error states. For the sake of 
simplicity we assume that B and C are disjoint. Infinite computations are taken 
into account by the difference between p, and v. This class of specifications 
includes all the CTL operators, and some kind of game specifications as well. 

In a framework using states, we use the predicate transformers pre ( y £ preX 
iff at least one successor of y is in X) and pre ( y £ preX iff all successors of y 
are in X). Then the specification is (with lgfp being either lfp or gfp): 

I C lgfp X.(A U {B n preX) U (C ft preX)). 

Since the class of specifications is stable by negation, we can choose to express 
the negation of the specification. Then it is expressed by the formula: 

I D lgfp X.(A U (B n preX) U (C D preX)) = 0 (1) 

Then, the goal of the analyzer is to over-approximate S = I fl lgfp X.(A U 
( B D preX) U (C fl preX)). If we get 0, we prove the property. Otherwise, we get 
initial states which may not satisfy the specification. 

2.3 Property Checking Driven Analysis 

The goal of our analyzer is to illustrate the technique of property checking driven 
analysis developed in [9]. In this section we give a summary of this technique. 
Starting from a concrete semantics S — I ft lgfp q !>, this method shows how to 
construct a lower closure operator 1 p such that: 

I n lgfp (p ° </>) = I n lgfp (j>. 

In this formula, p reduces the value obtained at each iteration of the fixpoint, 
while ensuring that the fixpoint will be greater than or equal to S. Hence, p 
focuses the fixpoint computation on parts useful for the computation of S. 

1 Lower closure operators are monotonic, reductive and idempotent. Basic results on 
lower closure operators are recalled in [9], 
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In practice, the fixpoints are transferee! into the abstract domain using ab- 
stract interpretation results, and an over-approximation p' of p is used. When p' 
is included in the abstract fixpoint computation, it leads to more precise (and 
still sound) results for S. Thus, the lower closure operator “drives” the analysis 
towards the verification of the specification. We can notice that this process does 
not change the abstraction itself, which is defined in the fixpoint transfer: it is 
not an abstraction refinement, but an analysis refinement. 

Some notation is necessary to exhibit the formulas expressing p. The lattice 
of lower closure operators on a domain D is written ( Ico ( D ) , C). A lower closure 
operator p is characterized by the set of its fixpoints p{D ), which is an upper 
Moore family: p(D) = M ( p(D )) = {UA | A C p(D)}. As usual, p will denote 
either the operator or the set of its fixpoints p(D), depending on the context. 

With (f = XX.(AU(BnpreX)U(CnpreX)), applying the results of [9] gives: 

po = AX.A n I 

p = lfp r].(p 0 U F^rj)) 

where F^ is a complex function defined in [9] . 

Here, p is constructed iteratively from po (the fixpoints of which are the 
subsets of /, i.e. all the possible values for S). Intuitively, at each iteration, F^ 
add as new fixpoints the minimum sets which can lead, by an application of </>, 
to a superset of an existing fixpoint X of p. All the fixpoints of p will then form a 
sub-lattice of p (X) on which we can restrict the computation of lgfp </>, without 
modifying the intersection of the fixpoint with I. 

To create a minimum set Y leading to a superset of A, we first test if X is 
included in AU BAC. If this is not the case, then we cannot define any Y since 
4>{X) 2 X. But if X C A U B U C, we construct a possible Y by choosing one 
successor for each element of X\B, and all the successors of X \ C. Then these 
sets are added as new fixpoints. 

As the approximation of p involves only looking for successors of states, 
we can consider it as our “forward” analysis (it starts from / and goes forward) 
which will “drive” the “backward” analysis lgfp (j). We show in [9] that this process 
can be iterated (as the result of the backward analysis can be used to get more 
precise guide) until a fixpoint is obtained. In practice, as was observed previously 
in other abstract interpretation-based analyzers which use backward-forward 
combination (e.g. in [2]), this fixpoint is reached after a few iterations. 



3 Construction of the Abstract Domain 

Of course, p is not computable, we use abstract interpretation to approximate it. 
Hence, we need to find abstractions on the domain of lower closure operators 2 . 
Identifying p by the set of its fixpoints, an over-approximation of p is simply a 
superset of p. 

2 Note that this abstraction is orthogonal to the abstraction of p (X) used in the 
computation of the abstract semantics. 
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Given a set of states X, we can see the application of p on X as the removal 
of states in X. A state a may be removed for two reasons: 

— The first case is that a ^ p{X). Then, a is not in any fixpoint of p , and er is 
totally useless for the computation of I D lgfp p ° (j>. This happens if a never 
appears in the computation of the “successors” of /. 

— There are some fixpoints of p which contain a, but none is included in X . 
In this case, a is removed because it is useless without other states. Such a 
state may be removed at some point during the computation of lgfp p ° 4>, 
and reintroduced later in the computation along with other states such that 
it is not removed. The construction of p presented in the previous section 
guarantees that any “useful” state for the computation of I fl lgfp 4> will 
eventually appear in the computation of lgfp p ° (f>. 

This distinction gives a starting point for the development of approximations 
for lower closures. The states appearing in our first case can be obtained through 
an approximation of p{E). As it is a subset of E , we can do that with any existing 
abstraction of E. To remove other states, we need some kind of dependence 
relations between useful states. Hence, a main issue of this work is to express 
the dependence (related to the temporal specification) between states. 

3.1 “Interval” Abstraction 

The “interval” abstraction is the only one described in [9]. From an abstraction 
of P to P# we derive an abstraction of Ico (P) where each lower closure p is 
represented by two elements of P*: an “upper” one which abstracts the greatest 
fixpoint of p, and a “lower” one which gives a lower bound on the non-empty 
fixpoints of p. 

Formally, from a Galois connection P ~ ; (P**,G#), we construct a new 
Galois connection Ico (P) * - (P®,3*0 x (P^ E®) defined as: 



Hence the lower bound gives the relations between the elements of P. The 
precision of these relations relies on the precision of the abstract intersection: 
{X £ P | a(X) C# n ^E} should be the smallest possible for a given E. 

Example 1. Applying this construction directly on a whole existing abstraction 
of p (A) is difficult and gives imprecise results (because the abstract intersection 
is not precise enough). Rather, we use it on abstractions of basic elements, and 
we use the result as a base for the construction of our abstract domain. 



a*(p) = (nHa(y)|yGp\{0}},a(p(I7))) 

7 *(Z,u) = {X j l C# a(X ) u} 



With the functional view of lower closures, 7 * becomes: 
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An example is given in [9] for integers, using the interval domain. We use the 
same approach to abstract Ico (p (I)): the initial abstract domain is (lx I, C), with 
(ai, 6 i) C (a 2 ,b 2 ) •<==>■ (a 2 < ai) A (b 1 < 62 ) (this is an extension of the interval 
domain, as we do not restrict ai to be less than bi), and a(X) = min A, max X. 

Then a lower closure p is abstracted by two intervals ((Mm, mM), (mm, 
MM)) 3 , such that: 



VX C I, p{X) C 



(0 

|lfl [mm, MM] 



if min X > Mm or max X < mM 
otherwise 



3.2 Abstraction of Ico (^(Iji)) 

The abstraction of lco(p(In)) can be deduced from an abstraction lco(p(I)), 
using the fact that Ij 7 = IU{17}. More generally, we study possible abstractions 
of Ico (p (A US)) (with A and B disjoint) using lco(p(A)) and lco(p(B)). A 
very simple abstraction is the non-relational abstraction: 

Proposition 1. Let A , B be two sets with AnB = 0. Then Ico (p (A U B)) < / , 
Ico (p(A)) x Ico ( p{B )) defined as: 

a(p) = (A X.p{X U B) n A), (A Y.p(A U Y) n B) 

7 (pa, Pb ) = (A Z.p A (Z n A) U p B {Z n B)) 

is a Galois connection. 

This abstraction is non-relational because it does not keep any constraints 
between the two sets. Applied for our domain of values, it would abstract 
Ico (p (In)) to lco(p(Tj) x {pii,pn}, such that p g = Ax.0 means that no er- 
ror appears in any fixpoint, whereas pn = Xx.x means that some fixpoints have 
arithmetic errors. 

However, it may be useful to know facts like “all non-empty fixpoints have 
arithmetic errors” (in this case, we can stop the analysis), so we will use three 
“possible error values” instead of two. To get this abstraction, we define the set 
T = {INI, ERR, TOP}, with the following intuitive meaning: 

— INI means that no error is possible. The lower closure associated p satisfies 
p(X) = p(X \ {12}) for all ICI fi . 

— ERR means that all elements of p, except 0, contains 17. Hence this is the 
“error” case. 

— TOP is the “do not know” answer. 

Then we construct an abstraction a from Ico (p (Ij?)) to Ico (p (I)) xT. Noting 
a\ (p), 0:2 (p) the two components of the abstraction, we define: 

ai (p) = XX.p(X U {17}) fl I 

( INI ifVXCI n ,p(X) =p(X\{f2}) 

a 2 (p) = < ERR if p ^ AX.0 A VX C I, p(X) = 0 
TOP otherwise 

3 Which stands for ( (max min, min max), (min min, max max) ), as these are in fact 
the bounds of the bounds of the non-empty fixpoints of p. 
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Fig. 1 . Lattice Ico (p (I)) x T, divided in three parts, one for each value of T. Note that 
({0}, INI) is the global bottom, and that ({0},TOP) is collapsed with ({0},ERR). 



Then Ico (p(I)) x T can be defined as a lattice with the structure defined 
Fig. 1, and a is the abstraction of a Galois connection. 

Our abstract domain of values is then Ij nt x T. This loses the relation between 
the fl and the non-error values in a same set in p. However, we keep the option 
“error everywhere”, which enables to know whether the error is not avoidable. 

3.3 Abstract Environment 

To abstract an environment, we need to abstract lower closures on powerset of 
Cartesian products. There is an intuitive non-relational abstraction (i.e. which 
abstracts each variable separately), but we will see that it is not sufficient in 
general, as it loses dependency information between source of non-determinism. 
Hence we will describe a weak relational abstraction which expresses the depen- 
dence between the possible values of several variables. 

Proposition 2 (Non-relational abstraction). LetA,B be two sets , andnA ■ 
p(A x B) p (A), 7 tb : p (A x B) — > p ( B ) the projections of subsets of Ax B 

7 

on their components. Then Ico (p (A x B )) < ; Ico (p (A)) x Ico (p ( B )) defined 

as: 

a(p) = (XX.tt a (p(X x B))), ( \Y.n B (p(A x Y))) 

7 {p A ,p B ) = (XZ.pa(tta(Z)) x p B (n B (Z))) 



is a Galois connection. 
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Hence, we can produce a non-relational abstraction of the whole environment, 
but this abstraction is not sufficient. Let us look at the following program: 

x := ? in [0,1] ; 
y := ? in [0,1] ; 
z := x + y 

If we want to prove that, by choosing the value for x and y, we can satisfy z = 2 
at the end of the program, we must know that x and y are independent before 
computing z (e.g. we do not have x = 1 — y). However, with a completely non- 
relational abstraction, we know that x and y can satisfy x = 1 and y = 1, but 
we do not know that these properties can be true simultaneously. The forward 
analysis would give the same result if we replace the second line by y := 1 — x. 

This limitation makes the analysis much less useful. Thus, we need to keep a 
kind of independence relation between variables, which is used to know that the 
constraints expressed on each variable are effective simultaneously. We do this 
by a weak relational abstraction, keeping only a relation between each variables. 



Weak relational abstraction: two variables case. First, we give a weak 
abstraction of Ico (p (!«)) x Ico (p(Ifi)) (like with two variables). Like the non- 
relational abstraction, we keep an abstract value for each component, but we add 
a boolean expressing the dependence between the components ( true means that 
the components may depend on each other) . Saying that x and y are independent 
in a lower closure p means that p is a Moore family generated by Cartesian 
products of sets of values (i.e., all the fixpoints of p are union of the Cartesian 
products generated by the fixpoints of the abstract values of each components). 

Hence, the abstract domain is Ico (p (Ij?)) x Ico (p (Ij?)) x B. The concretiza- 
tion of (p x , p y , false), expressed as a Moore family, is p = A4(X xY \ X £ 
p x !\Y £ p y ): p is generated by Cartesian products. The concretization of 
(Px,p y , true) is p = {Z £ p( If?) x p(ln) | 7 r x (Z) £ p x A w y (Z) £ p y } with 
7r X (Z) (resp. 7 r y (Z)) the projection of Z to its first (resp. second) component: 
this is the non-relational concretization of ( p x ,p y )• 

Example 2. To illustrate our abstraction, we restrict the values to S = {0, 1}. 
We want to study an abstraction of Ico (p (S x S)) to Ico (p ( S )) x Ico (p ( S )) xB, 
or, more precisely, we want to describe the meaning of the abstract values. To 
simplify, we suppose that the first component of the abstract value is {0, {0, 1}}, 
and that the second satisfies p({0, 1}) = {0, 1}. Still, we have eight possible cases 
(four values for the second lower closure, and two for the boolean), all described 
in Fig. 2, with the order between them. When the boolean is false, the values 
are independent, which means that all the generators of the lower closure are 
Cartesian products, whereas when the boolean is true we can keep any generator. 

The relation is very weak, and its meaning is restricted to the “lower” part 
of the abstraction, but it is sufficient to keep the independence of the random 
generators, which was our goal. In particular, the abstract functions will be easier 
to compute than with stronger relations like octagons[10]. 
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Fig. 2. The eight cases of example 2. Each case is described by the value of the boolean, 
and the generators of the second lower closure operator in the abstract value. For each 
case, we give the generators of the concretized lower closure. We give also the order 
between them. We can see that adding the independence boolean (case false) restrict 
greatly the concrete lower closure. 



Weak relational abstraction: general case. Our first generic abstract do- 
main is (¥ — > Ico (p(Ift))) x p(p(V)), with the concretization: 

l(f,B) = {Z | \/x G ¥,7 r x (Z) G f(x) A W ^ B,n v {Z) = x xeV -K x (Z)} 

The principle is to associate a boolean to any subset V of ¥, describing the 
idea that these variables are “globally” dependent. Note that three variables may 
be “independent” when taken pairwise without being “globally” independent (a 
set of points in dimension 3 may look like a Cartesian product when projected 
in any direction, but not be itself a Cartesian product, cf. Fig 3 for an exam- 
ple). Thus we cannot deduce exactly the “global” dependence function from the 
dependence relations between pairs of variables. 
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Fig. 3. An example of a set of 3-dimensional points which gives Cartesian products 
when projected in every direction, but is not a Cartesian product. 



However, keeping an element of p (p (V))) is too costly and, in practice, it is 
not useful 4 . Rather, we keep only a symmetric relation between variables (i.e. a 
subset of p (V x V)) expressing the dependence of the variables, but such that all 
sets of variables completely unrelated must be globally independent (thus, this 
is a subset of the real dependence relations between each couple of variables, but 
from it we can reconstruct the whole set of dependencies) . This construction can 
be viewed as an abstraction (as we construct a sound, but not complete, “global” 
dependence function), where the concretization function yy between p(V x V) 
and p(p(V))) is: 

7v(i?) = {{vi} ieA | 3(i, j) e A 2 , (vi,Vj) € R}. 

Hence, the domain of abstract environments is (Y — > lint x T) x p(V x V). 
Due to this relational abstraction, we do not have a best abstraction function 
a, but we still have the concretization function 7. Though we cannot use the 
Galois connection framework, we can use the frameworks developed in [5]. 



3.4 Abstract Domain 

With the abstract domain constructed above, we can use the non-relational 
abstraction developed for powerset of unions: 

Ico (p (Lab x (V — *• Ifi))) < 7 > Lab — > Ico (p (Y — > 1^)) 

O' 

This abstraction forgets information on conditionals and loops. This may be 
a problem, for example, with the program: 

x:= ? in [0,1] ; 

if (x=0) then x:=0 else x:=l ; 

4 It appears to be difficult to infer the dependencies with this level of precision. 
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(1) Initial states: / 

> x:= ? in {0,1} 

Lj y:= ? in { 0 , 1 } 

(4) X ' X ^ Final states: F : a; = 1 



1 { x:[{ ini: (-oo,+oo,-oo,+oo) }]; y:[{ ini: (-oo,-too,-oo,+oo) },x] } 


1 { BOT } 




2 {x:[{ ini: (0,1 ,0,1) }]; y:[{ ini: (-oo,+oo,-oo,+oo) },x] } 


2 { BOT } 




3 { x:[{ ini: (0,1 ,0,1) }]; y:[{ ini: (0,0,1, 1) }] } 


3 {BOT} 




4 { x:[{ ini: (0,1 ,1 ,2) }]; y:[{ ini: (0,0,1 ,1 ) },x] } 


4 { x:[{ ini: (1 ,1 ,1 ,1) }]: y:[{ ini: (0,0,1 ,1)},x]} 





Result after a forward analysis. Result after a forward analysis 

followed by a backward analysis. 



Fig. 4. Example described in section 4.1: program and results. 



Before the test, there is only one non-empty fixpoint for x ({0, 1}), but after the 
test, we get two fixpoints ({0},{1}). Hence we lose information. In practice, we 
think that it is possible to deal with this issue without modifying the abstract 
domain, by a good implementation of the abstract test during the backward 
analysis. Here, it means that we should be able to see that both branches of 
the test are taken. Hence, if one branch can not satisfy the specification, the 
backward analysis must propagate that the specification is not satisfied. 

4 Examples of Analyses 

We wrote a prototype analyzer in OCaml with a graphical interface, from 
Cousot’s Marktoberdorf generic analyzer [3]. The abstract domain for p (17) 
is the domain of intervals, and the abstract domain for lower closures is the 
domain defined in the previous section. As a simple prototype, we did not try 
to optimize the abstract operations. Thus, its complexity is exponential in the 
depth of the nested loops, cubic in the number of variables and linear in the size 
of the program. 

4.1 First Example 

We analyse the very small program presented, with its results, in Fig. 4. 

The first random generator (for x) is “internal”, whereas the second (for y) 
is “external”. The initial states are the non-error states of program point (1), 
and the final states are the states of program point (4) satisfying x = 1. The 
specification is that it is not possible to reach the final state when only the value 
of x is chosen 5 . Using the notations of the formula (1), it means that A = F, C 
are the states at program point (2), and B are the other states. 



5 This example was given in [8] as a verification which does not work with interval 
analysis. 
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For each program point and each variable, we give: 

1. The error status (ini, err or top), corresponding to the values of T. 

2. Four integers (mm, Mm, mM, MM) describing the possible values of the 
variables. Informally, it means that for each generator, the variable has a 
value in [mm, Mm) and in [mM, MM). We changed the order of the integers 
(compared with section 3.1) so that this informal definition is more readable. 

3. The list of variables which are dependent of this variable. Since the relation 
of dependence is symmetric, we give it only once. 

For example, in program point (3), with only the forward analysis, we get 
x : [ ini : (0, 1,0,1) ]; y:[ ini : (0,0, 1,1) ], which means informally that 
x is in {0, 1}, y is in {0, 1} and takes all values in {0, 1} whatever the value of 
x (as they are independent). If the computations were exact, the generators of 
the concrete lower closure operators would be {{(a: : 0, y : 0), (x : 0, y : 1)}, {(cc : 
1,2/ : 0),(a; : 1 ,y : 1)}}, which are exactly the concretization of the abstract 
environment. Here we do not lose information. 

In program point (4), the result means that x is in [0,2] and takes at least 
one value in [0, 1] and one value in [1, 2], y takes all the values of [0, 1], and the 
two variables are dependent. Note that the real generators would be {{(a; : 0, y : 
0),(x : l,y : 1)}, {(aa : l,y : 0),(x : 2, y : 1)}. We lose much information, but 
thanks to the following backward analysis this is not a problem. 

With a backward analysis following the forward analysis, we get x = 1 in 
program point (4), and y takes all the values in [0, 1], which gives the elements 
{(a; : l,y : 0), (x : 1 ,y: 1)}, Hence, in program point (3), it yields {(a; : 1 ,y: 
0),(x : 0,2/ : 1)} which is not possible given the fact that x and y must be 
independent. Thus, the application of the lower closure operator gives B0T (which 
represents _L), which proves our specification. 

4.2 Second Example 

The program we analyse is described in Fig. 5. Here again we have two random 
operations. The first one (for the test) is internal, whereas the second (for n) is 
external. We want to be sure that by controlling the test, we can prevent x = 0 
after the loop. Hence, with the notation of the equation 1, A = F, C are the 
states at program point (2), and B are the other states. The result of the analysis 
is given Fig. 5. Since we get T for the initial point after the backward analysis, 
the analyzer proved our specification. 

The difficult point in this analysis is the backward computation at program 
point (2). The analyzer detects that both branches of the analyzer are taken, 
independently of the variables x and n, using the weak relational analysis. Thus, 
it computes an intersection of the environments of program points (3) and (5). 

5 Discussion 

In this section we examine the improvement obtained by property-checking 
driven analyses, with respect to the precision of the analysis. 
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(0) 

(1) 

( 2 ) 

(3) 

(4) 

(5) 

(6) 

(7) 

(8) 
(9) 



Initial states: F : x = 1 

while (n>0) do { 

if (? in [0,1] =0) then 
x = x * (n-1) ; 

else 

x = x * n; 
fi 

n = n - (? in [0,1]); 

J Final states: F : x = 0 



0 { n:[{ ini: (-oo,+oo,-oo,+oo) }]; x:[{ ini: (1 ,1 ,1 ,1) },n] } 0 

1 { n:[{ ini: (-oo,+oo,-oo,+oo) }]; x:[{ ini: (0, + 00 , 0 , +oo) },n] ) i 

2 { n:[{ ini: (1 ,+oo,1 ,+oo) }]; x:[{ ini: (0,+oo,0,+oo) ),n] } 2 

3 { n:[{ ini: (1 ,+oo,1 ,+oo) }]; x:[{ ini: (0,+oo,0,+oo) },n] } 3 

4 { n:[{ ini: (1 ,+oo,1 ,+oo) )]; x:[{ ini: (0,+oo,0,+oo) },n] } 4 

5 { n:[{ ini: (1 ,+oo,1 ,+oo) }]; x:[( ini: (0,+oo,0,+oo) },n] } 5 

6 { n:[{ ini: (1 ,+oo,1 ,+oo) }]; x:[{ ini: (0,+oo,0,+oo) },n] } 6 

7 { n:[{ ini: (1 ,+oo,1 ,+oo) }]; x:[{ ini: (0,+oo,0,+oo) },n] } 7 

8 { n:[{ ini: (0,+oo,0,+oo) }j; X:[{ ini: (0,+oo,0,+oo) },n] } 8 

9 { n:[{ ini: (-oo,0,-oo,0) ]]; x:[{ ini. (0,+oo,0,+oo) },n] ) 9 



{ BOT } 

{ n:[{ ini: (-oo,+oo,-oo,+oo) }]; x:[( ini: (0,0, 0,0) },n] } 
{ n [{ ini: (1 ,+oo,1 ,+oo) )]; x:[{ ini: (0,0, 0,0) ),n] ) 

{ n:[{ ini: (1, +00,1, +00) }]; x:[{ ini: (0,+oo,0,+OO) },n] ) 
{ n :[{ ini: (1 ,+oo,1 ,+oo) )]; x:[{ ini: (0,0, 0,0) ),n] ) 

{ n:[{ ini: (1 ,+oo,1 ,+ooj }]; x:[{ ini: (0,0, 0,0) },n] ) 

{ n [{ ini: (1 ,+oo,1 ,+ 00 ) }]; x:[{ ini: (0,0, 0,0) },nj } 

{ ri [{ ini: (1 ,+oo,1 ,+oc) )]; x:[{ ini: (0,0, 0,0) },n] ) 

{ n:j{ ini: (0,+oo,0,+oo) )]; x:[{ ini: (0,0, 0,0) },n] } 

{ n ({ ini: (-oo,0,-oo,0) }]; x:[{ ini: (0,0, 0,0) ),nj } 



Result after a forward analysis. Result after a forward analysis 

followed by a backward analysis. 



Fig. 5. Example of section 4.2: program and results. 



Starting from the definition of S (as in equation (1)), the first idea to overap- 
proximate S with abstract interpretation-based analyses is to choose an abstract 
domain, develop in this abstract domain approximations for pre and pre, and 
directly approximate the fixpoint using the fixpoint transfer theorem. A more 
precise method, still easier than property-checking driven analysis, is to com- 
bine the previous analysis with a reachability analysis starting from /, a method 
proposed in [7]. This method gives a back ward- for ward analysis quite similar to 
ours, but which does not use the lower closure framework. Thus, comparing the 
two analyses is a good method to see what is gained with this framework. 

The first thing we can see is that when the specification does not use pre 
(e.g. we just want to prove that some states are unreachable), our technique is 
useless. Then the analysis is at worst as imprecise as a classical interval analysis 
(though the complexity is worse). 

To show that our analysis can be useful, let us examine a very small example: 

I : y £] — oo, +oo[ 

x : = ? in [0,2] ; 
y:= f (x,y) ; 

A: ye [ 0 , 8 ] 

Here, f (x,y) should be read as an arbitrary expression depending on x and 
y, e.g. x + y or x*y. We want y to be in [0, 8] at the end of the program, whatever 
the result of the non-deterministic operator. 
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A “classical” analyzer will know that x is in [0,2] when f(x,y) is computed. 
In the backward analysis, it must be able to carry a relation between x and y, 
sufficient to deduce the correct constraints on y when it analyses the command 
x : = ? in [0,2]. The relation the analyzer can carry is closely related to the 
abstract domain, and may not be suitable for the function /. 

On the other hand, our analyzer can deduce precise constraints on y directly 
during the backward analysis of y := /(a;,?/), knowing that x must take the 
values 0 and 2. Hence it does not need to transmit complex relations. 

Let us consider this example when f(x,y) = x *y. Even with an expensive 
abstract domain like polyhedra, we cannot express the good relation between 
x and y, and the result of the analysis remain imprecise (i.e. it finds that y is 
in [—oo, +oo] at the beginning of the program). Whereas our analyzer finds that 
y must take values in [0,4], which is the optimal solution. This example shows 
that our approach can give better results than the traditional approach, even 
with expensive abstract domains. 

6 Conclusion and Future Work 

We presented in this paper the construction of an abstract domain used in a 
small prototype analyzer for automatic program verification of temporal proper- 
ties. This analyzer uses a technique based on lower closure operators to exploit 
the information given by the specification in the analysis. We showed how to 
abstract the domain of lower closure operators, from the classical interval ab- 
straction, to keep relational information about the states of the program. Even 
with these weak abstractions, the method may give more precise results than 
classical abstract analyses with expensive relational domains. Though we anal- 
yse only a small class of specifications, the same method can be used for larger 
classes by including temporal formulas in the concrete domain of the semantics 
(as was done in [8]). 

Our analyzer uses similar abstractions for both analyses (the direct one, on 
sets of states, and the “reverse” one, on lower closures). Future work can stem 
from the idea that these abstractions are, in fact, orthogonal. Thus, we can 
use our abstractions on lower closures along with polyhedra on sets of states, 
improving the precision of the analysis (without designing a complex abstraction 
on lower closures based on polyhedra). In general, we believe that property- 
checking driven analysis can be applied to other abstraction-related analyses. 
Especially, it would be interesting to examine exactly how it can be compared 
with abstraction refinements and domain completions [6] and how we can use 
both technique efficiently. 
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Abstract. We present a general method to achieve modularity of se- 
mantic definitions of programming languages specified as rewrite theo- 
ries. This provides modularity for a language specification method that 
combines and extends the best features of both SOS and algebraic seman- 
tics. The relationship to Mosses’ modular operational semantics (MSOS) 
is explored in detail, yielding a semantics-preserving translation that 
could support execution and analysis of MSOS specifications in Maude. 



1 Introduction 

This work presents a general method to achieve modularity of semantic defini- 
tions of programming languages specified as theories in rewriting logic [16,6], 
a logical framework which can naturally represent many different logics, lan- 
guages, operational semantics formalisms, and models of computation [16, 14, 
15]. Since equational logic is a sublogic of rewriting logic, this language spec- 
ification style generalizes the well-known algebraic semantics of programming 
languages (see, e.g., [13] for an early paper, [24] for the relationship with action 
semantics, and [12] for a recent textbook). The point of this generalization is 
that equational logic is well suited for specifying deterministic languages, but 
ill suited for concurrent language specification. In rewriting logic, deterministic 
features are described by equations, but concurrent ones are instead described by 
rewrite rules with a concurrent transition semantics. Our modularity techniques 
yield also new modularity techniques for algebraic semantics as a special case. 

It has also been clear from the early stages [16, 20, 14] that there is a natu- 
ral semantic mapping of structural operational semantics (SOS) definitions [27] 
into rewriting logic. In essence, an SOS rule is mapped to a conditional rewrite 
rule. In a sense, we can view rewriting logic semantics as a synthesis of algebraic 
semantics and SOS, that adds a crucial distinction between equations and rules 
(determinism vs. concurrency) missing in each of those two formalisms. This dis- 
tinction is of more than academic interest. The point is that, since rewriting with 
rules R takes place modido the equations E [16], only the rules R contribute to the 
size of a system’s state space, which can be drastically smaller than if all axioms 
had been given as rules. This observation, combined with the fact that rewrit- 
ing logic has several high-performance implementations [1,11,8] and associated 
formal verification tools [9, 15], means that we can use rewriting logic language 
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definitions to obtain practical language analysis tools for free. For example, in 
the JavaFAN formal analysis tool [10] the semantics of the JVM is defined as 
a rewrite theory in Maude which is then used to perform formal analyses such 
as symbolic simulation, search, and LTL model checking of Java programs with 
a performance that compares favorably with that of other Java analysis tools. 
Indeed, the fact that rewriting logic specifications provide in practice an easy 
way to develop executable formal definitions of programming languages, which 
can then be subjected to different tool-supported formal analyses, is by now well 
established [33, 2, 34, 30, 29, 18, 31, 7, 28, 32, 10] . 

The new question that this work addresses is: how can rewriting logic spec- 
ifications of programming languages be made modular, so that the semantics 
of each feature can be given once and for all, instead of having to redefine 
the semantic axioms in a language extension? In this regard, we have learned 
much from Mosses’ elegant solution to the SOS modularity problem though his 
modular structural operational semantics (MSOS) [23,25,26,22]. To maximize 
modularity and extensibility, the techniques we propose make the semantic rules 
as abstract and as general as possible using two key ideas: record inheritance 
through associative commutative matching (a technique also used in MSOS); 
and systematic use of abstract interfaces. We compare in detail our modularity 
techniques with those of MSOS. This takes the form of a translation map r 
mapping an MSOS specification to an (also modular) rewrite theory. The map r 
has very strong semantics-preserving properties, including a bisimilarity result 
between transition systems for an MSOS specification and its resulting trans- 
lation. This work further advances a line of joint work with Hermann Haeusler 
and Peter Mosses on semantics-preserving translations from MSOS to rewriting 
logic [3,2,4]. The translation r and its properties are discussed in Section 4. As 
for the rest of the paper, Section 2 summarizes prerequisites, Section 3 presents 
our modularity techniques, and Section 5 gives some conclusions. 

2 Membership Equational Logic and Rewriting Logic 

We gather here prerequisites about membership equational logic (mel) [17] and 
rewriting logic [16,6]. Maude 2.0 [8] supports all the logical features described 
below, with a syntax almost identical to the mathematical notation. 

2.1 Membership Equational Logic 

A MEL signature is a triple ( K,£,S ) (just A in the following), with K a set 
of kinds, £ = {£w,k}(w,k)eK xk a many-kinded signature and S = {Sk}k&K 
a A'-kinded family of disjoint sets of sorts. The kind of a sort s is denoted by 
[s]. A MEL A-algebra A contains a set Ak for each kind k € K, a function 
Af : Afc x x • • • x Ak n — > Ak for each operator / e £k 1 --k„,k and a subset A s C Ak 
for each sort s € Sk, with the meaning that the elements in sorts are well- 
defined, while elements without a sort are errors. We write T s,k and TV(X)fc 
to denote respectively the set of ground A-terms with kind k and of A-terms 
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t £ T s (X) k 
(VX) t -*■ t 



Reflexivity 



(VX) fa -> fa, (VX) fa 
(VX) fa -> ts 



fa 



Transitivity 



E b (VX) t = u, (VX) u ■ 



E b (VX) = t' 



(VX) t -► fa 



Equality 



/ € Ek 1 -k n ,k, fa, fa £ Ts(X)fc i for i€{l,...,n} 
fa = ti for i £ <f>(f), (VX) fa -*• fa for j £ u(f) 
(VX) /(fa,...,t„)-/(ti,...,^) 



Congruence 



(VX) r: t -> t' if Aig/Pi — ft A A jgj : X A Aigz, fa —> t\ €. R 

0,0'\ X Ts(y), 0(*) = 6»'(x) for x € <j>{t,t') 

E h (VF) 0(pi) = 0{ qi ) for i € I, E b (VF) 6»( Wj ) : for j£ J 

(VF) 6»(fa) — ► e(t{) for l £ L, (\/Y) 0{x) -> e'(x) for x £ Nested 

(VF) 6»(t) -> e'(t') Replacement 



Fig. 1. Deduction rules for rewriting logic. 



with kind k over variables in X, where X = {a;i : k\,. . .,x n : k n } is a set of 
kinded variables. Given a MEL signature X, atomic formulae have either the 
form t = t' (X-equation) or t : s (X-memberslrip) with t,t' £ T^(X)fc and 
s £ Sk’, and X -sentences are conditional formulae of the form (VX) <p if /\ i Pi = 
<H A f\j Wj : Sj, where ip is either a X-equation or a X-membership, and all 
the variables in ip, pi, qi, and Wj are in X. A MEL theory is a pair (X, E) 
with X a MEL signature and E a set of X-sentences. We refer to [17] for the 
detailed presentation of (X, X)-algebras, sound and complete deduction rules, 
and initial and free algebras. Order-sorted notation Si < S 2 can be used to 
abbreviate the conditional membership (Vx : k) x : S 2 if x : S\. Similarly, an 
operator declaration / : si x • • • x s n — * s corresponds to declaring / at the kind 
level and giving the membership axiom (Vxi : k \, . . . ,x n : k n ) f(x ±, . . . , x n ) : 
s if A i<i< n x i ■ Si - W e write (Vaq : s\,...,x n : s n ) t = t’ in place of (Vaq : 

k\, . . . , X n . kjf) t — t if Al<i<n * "-V* 

2.2 Rewrite Theories and Deduction 

We present the general version of rewrite theories over MEL theories defined 
in [6]. A rewrite theory is a tuple 1Z = ( E,E,<f>,R ) consisting of: (i) a MEL 
theory (X, E); (ii) a function (j>: X — > pf (N) assigning to each function symbol 
/: k\ ■ ■ ■ k n — > k in X a set 4>{f) C {1, . . . , n} of frozen argument positions’, (iii) 
a set R of (universally quantified) labeled conditional rewrite rules r having the 
general form 
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(VX) r: t —> 1/ if A ieI Pi = Qi A A je j wj : sj A A; £ l l 'i (!) 

where, for appropriate kinds k and fcj in K, t,t' £ Tj;(X)fc and t\,t\ £ Tz;(X)i tl 
for l £ L. 

The function <f> specifies which arguments of a function symbol / cannot be 
rewritten, which are called frozen positions. Note that if the ith position of / 
is frozen, then in /(f 1; . . . ,t n ) any subterm of t t becomes also frozen. That is, 
the freezing idea extends to subterms and in particular to variables. Given two 
terms t. 1' we can then define the sets <f>(t,t') and v(t,t') of their frozen (resp. 
unfrozen) variables (see [6]). Given a rewrite theory 1Z = (£, R), a sequent 

of 1Z is a pair of (universally quantified) terms of the same kind t, t' , denoted 
(VX)t — > t' with X = {aq : k\,...,x n : k n } a set of kinded variables and 
t,t! £ Ts{X)k for some k. We say that 1Z entails the sequent (VX) t —> t' , and 
write 1Z b (VX) t — > t! , if the sequent (VX) t — > t' can be obtained by means of 
the inference rules in Figure 1. (Reflexivity), (Transitivity), and (Equality) 
are the usual rules for idle rewrites, concatenation of rewrites, and rewriting 
modulo the MEL theory E. (Congruence) allows rewriting the arguments of 
a generalized operator, subject to the condition that frozen arguments must 
stay idle. (Nested Replacement) characterizes the concurrent application of 
a rewrite rule in its most general form (1). 

3 Modular Language Specifications in Rewriting Logic 

Modularity is only meaningful in the context of an incremental specification, 
where syntax and corresponding semantic axioms are introduced for groups of 
related features. We can describe an incremental presentation of the syntax of 
a programming language C as an indexed family of syntax definitions {£;}*£/> 
where the index set I is a poset with a top element T, such that: (i) if i < j, 
then Ci C Cj, and (ii) C -p = C. An incremental rewriting semantics for C 
is then an indexed family of rewrite theories {7Acj}iei> with 7 Zc t defining the 
semantics of the language fragment Ci. Modularity of the incremental rewriting 
semantics { TZc , = (T), Ei,<j>i, Ri)}i^i means in essence two things. First of all, it 
should satisfy the following monotonicity property: if i < j, then there is a theory 
inclusion TZc t Q TZc, ■ This is not easy to achieve, but one can always achieve it 
a posteriori, by carving out submodules of the top module TZc for each of the 
language fragments Ci. This way of “cheating” can be immediately recognized 
by asking the specifier to tell us what the SOS rules are going to be when new 
features are added in a further extension. Therefore, besides monotonicity, we 
need the second requirement of extensibility. This, together with monotonicity, 
means that the semantics of each language feature can be defined once and 
for all, so that we never have to retract earlier semantic definitions in a later 
language extension. One is then interested in methods that can be used to develop 
incremental rewriting semantics definitions of programming languages that are 
as modular as possible. 

The method we propose uses pairs, called configurations', the first component 
is the program text, and the second a record with the different semantic entities 
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that change as the program is computed. That is, we organize all the semantic 
entities associated to a program’s computation in a record data structure. For 
example, one of the record’s fields may be the store , another the environment of 
declarations, and yet another the traces left by a concurrent process’ execution. 
We can specify configurations in Maude with the following membership equa- 
tional theory (a functional module importing the RECORD module shown later in 
protecting mode, that is, adding no more data (“no junk”) and no new equal- 
ities (“no confusion”) to records; the ctor keyword indicates a constructor ): 

fmod CDNF is 
protecting RECORD . 
sorts Program Conf . 

op : Program Record -> Conf [ctor] . 

endfm 

The first key modularity technique is record inheritance , which is accom- 
plished through pattern matching modulo associativity, commutativity, and iden- 
tity. Features added later to a language may necessitate adding new semantic 
components to the record; but the axioms of older features can be given once 
and for all in full generality: they will apply just the same with new components 
in the record. Here is the Maude specification of the membership equational 
theory of records. Note Maude’s convention of identifying kinds with connected 
components in the subsort inclusion poset, and naming them as equivalence 
classes of sorts in such components. For example, [PreRecord] denotes the kind 
determined by the connected component {Field, PreRecord}. 

fmod RECORD is 

sorts Index Component Field PreRecord Record Truth . 
subsort Field < PreRecord . 
op tt : -> Truth . 
op null : -> PreRecord [ctor] . 

op : PreRecord PreRecord -> PreRecord [ctor assoc comm id: null] . 

op _ : _ : [Index] [Component] -> [Field] [ctor] . 
op {_} : [PreRecord] -> [Record] [ctor] . 
op duplicated : [PreRecord] -> [Truth] . 

var I : Index . vars C C’ : Component . var PR : PreRecord . 
eq duplicated( (I : C) , (I : C’), PR) = tt . 
cmb {PR} : Record if duplicated (PR) =/= tt . 
endfm 

A Field is defined as a pair of an Index and a Component; illegal pairs will 
be of kind [Field] . A PreRecord is a possibly empty (null) multiset of fields, 
formed with the union operator which is declared to be associative (assoc), 
commutative (comm) and to have null as its identity (id). Maude will then 
apply all equations and rules modulo such equational axioms [8]. Note the con- 
ditional membership (cmb) defining a Record as an “encapsulated” PreRecord 
with no duplicated fields. Record inheritance means that we can always consider 
a record with more fields as a special case of one with fewer fields. Matching 
modulo associativity, commutativity, and identity supports record inheritance, 
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because we can always use an extra variable PR of sort PreRecord to match any 
extra fields the record may have. For example, a function get-env extracting the 
environment component can be defined by 

eq get-env({env : E , PR}) = E . 

and will apply to records with any extra fields that are matched by PR. 

The second key modularity technique is the systematic use of abstract in- 
terfaces. That is, the sorts specifying key syntactic and semantic entities (e.g., 
Program, Store, Env) are abstract sorts for which we: 

— only specify the abstract functions manipulating them, that is, a given sig- 
nature , or interface, of abstract sorts and functions; no axioms are specified 
about such functions at the level of abstract sorts', 

— in a language specification no concrete syntactic or semantic sorts are ever 
identified with abstract sorts: they are always either specified as subsorts of 
corresponding abstract sorts, or mapped to abstract sorts by coercions', it is 
only at the level of such concrete sorts that axioms about abstract functions 
(e.g., functions manipulating the store) are specified. 

This means that we make no a priori ontological commitments as to the nature of 
the syntactic or semantic entities. It also means that, since the only commitments 
ever made happen always at the level of concrete sorts, one remains forever free 
to introduce new meaning and structure in any language extension. 

A third modularity technique regards the form of the rules. We require that 
the rewrite rules in the rewrite theories 7 Zc t are semantic rules 

(f(t i,...,t n ),u) — >{t',u') if C, 

where / is a language feature, e.g., if-then-else, u and u' are record expres- 
sions, and u contains a variable PR of sort PreRecord standing for unspecified 
additional fields and allowing the rule to match by record inheritance. In addi- 
tion, the following information hiding discipline should be followed in u, u' , and 
in any record expressions appearing in C : besides basic record syntax, only func- 
tion symbols appearing in the abstract interfaces of some of the record’s fields 
can appear in record expressions; any auxiliary functions defined in concrete 
sorts of those field’s components should never be mentioned. This information 
hiding makes the rules highly extensible, because the concrete representations 
of the auxiliary semantic entities can be changed or extended without having to 
change the rules at all. For example, we can change or extend the internal rep- 
resentations of traces, stores, or environments, without the rules being affected 
in any way: all we have to do is add new equations defining the semantics of the 
abstract functions on the new concrete data representations. For two interesting 
applications of this modularity discipline, one in which the semantics of CCS is 
extended from the strong transition semantics to the weak transition semantics, 
and another in which the be sublanguage of C is enriched with annotations for 
physical units in the style of [7], so that the values stored now need to be pairs of 
a number and a unit expression, see [5] . Another example illustrating our general 
methodology is given in [19], Appendices A-B. 
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The combination of these three techniques can be of great help in making 
semantic definitions modular and easily extensible. That is, we can develop in 
this way modular incremental semantic definitions for a language C as a poset- 
indexed hierarchy {7 Zci = (Hi, Hi, <pi, 7?;)}i e j of rewrite theory inclusions , with 
the full language definition as the top theory in the hierarchy and with the theory 
CONF - which contains RECORD as the bottom of the hierarchy. By following 
the methods described above, such a modular definition will then be much more 
easily extensible than if such methods had not been followed. As we explain in 
more detail in Section 4, the above methods are closely related to Mosses’ MSOS 
methodology; however, besides the fact that we are exploring such methods in 
a different semantic framework, it appears that our systematic use of abstract 
interfaces is an aspect considerably less developed in the MSOS approach. 

An important variant of our approach is to choose the MEL sublogic of rewrit- 
ing logic as the logical framework in which to define the semantics of a language. 
As argued in [18], this is a perfectly good possibility for sequential or determin- 
istic languages, but is typically a bad choice for concurrent languages. Of course, 
in this case the semantics is no longer given by rewrite rules, but by conditional 
equations of the form, 



(f(h,...,t n ),u) = ( t',u ') if C. 

This variant provides modularity techniques for a long strand of work in the 
so-called algebraic or initial algebra semantics of programming languages (see, 
e.g., [13,24,12]). In fact, as explained in the Introduction, the best approach in 
practice is to combine the equational and the rewriting variants of the modular 
language specification methodology just described. This is easy in rewriting logic, 
because of its explicit distinction between equations and rules. 



3.1 Controlling Rewrite Steps in Conditions 

When relating SOS rules to rewrite rules a few technicalities are needed to 
obtain an exact correspondence. The key issue is the number of steps of rewrites 
in conditions. In an SOS rule 

A— *P1 ... Pu— >P’ n 
Q — >Q' 

the rewrites I\ — > P[ in the condition are one-step rewrites. By contrast, in a 
rewrite rule 

Q — >Q' if Pi — ► P[ A ... A P n — ► P’ n , 

because of the (Reflexivity) and (Transitivity) inference rules of rewriting 
logic (see Figure 1) the rewrites P t — > P[ in the condition are considerably more 
general: they can have zero, one, or more steps of rewriting. The point is that, 
by definition, in rewriting logic all finitary computations are always derivable as 
sequents , whereas in SOS they are not, unless special provisions are made such 
as a big-step style or adding transitivity as an explicit SOS rule. The question we 
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now address is how to accomplish two simultaneous goals: (i) to represent SOS 
rules in an exact way, with one step rewrites in conditions; and (ii) to get also 
all Unitary computations in the rewriting logic representation, so that we always 
get a language interpreter, even when the SOS rules do not directly provide one. 
To accomplish goals (i) and (ii) , we extend the module CONF to a system module 
(rewrite theory): 

mod RCDNF is extending CDNF . 
op : [Program] [Record] -> [Conf] [ctor] . 

op [_,_] : [Program] [Record] -> [Conf] [ctor] . 
vars P P’ : Program . vars R R’ : Record . 

crl [step] : < P , R > => < P’ , R’ > if { P , R } => [ P’ , R> ] . 
endm 

We furthermore require semantic rewrite rules to be of the form, 

{t,u} — >[t',u'] if {vi,wx} — >[v[,w[] A ... A {v n ,w n } — » [v' n ,w' n ] A C, 

(2) 

where n > 0, and C is a (possibly empty) equational condition involving only 
equations and memberships. Note that a rewrite theory 7 Z containing only RCONF 
and rules of the form (2) will be such that one-step rewrites correspond to proofs 
of sequents 1Z b {v, u>} — > [v ' , w/], whereas Unitary computations correspond to 
proofs of sequents 1Z b (v,w) — * (v',w'}. 

4 Relationship to MSOS 

Our modular rewriting logic ideas have a close relationship to a new formulation 
of MSOS initiated in [26] and further developed by Peter Mosses under the 
name of definitive semantics [21,22]. This allows us to define a quite succinct 
mapping from MSOS to rewriting logic that is semantics-preserving in a very 
strong sense. In Mosses’ definitive semantics, labeled transitions are of the form 
t — » t' , where t,t' are program expressions (which can involve values), and u is 
a record which specifies the semantic information before and after the transition 
takes place. This is accomplished by postulating that the indices of the record 
are classified in three different types: 

— read-only , where the index, say i, is a name with no additional structure; 

— write-only , where the index has primed form, that is, is of the form i'\ and 

— read-write, where there are in fact two indices in the record: a plain i, and 
its primed variant i' . 

Furthermore, the values of any write only index must range over some free 

monoid of lists, with an associative append operation and neutral element nil. 

For example, an environment index env will be read-only, a trace index tr' for a 
concurrent process will be write only, and store indices st, st' will be read-write. 
As usual, the primed indices indicate the relevant changes after the transition 
takes place. Such records can be naturally viewed as the arrows of a label category, 
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so that several-step computations 1 can be defined by composing the labels and 

forgetting the intermediate stages as follows: (t — t')\ (■ t ' t") = ( t t"). 

For the composition u; u' to be defined, we must have (in usual record nota- 
tion) u.i = u' .i for each read-only index i, and u.j' = u' .j for each read-write 
index j. The composition u;u' then has ( u;u').i = u.i = u'.i, ( u;u').j = u.j, 
(u\u').j' = u! .j' , and (u;u').k = (u.k).(u'.k) for each write-only index k. Iden- 
tities are then records u such that u.j = u.j', and u.k = nil. Note that we 
can easily axiomatize these records and their composition and units in an ex- 
tension of our RECORD module. In particular, we will have a subsort IRecord < 
Record of identity records, another subsort IPreRecord < PreRecord of iden- 
tity prerecords, and a partial record composition operator In what follows we 
will use variables X, X' . . ., of sort Record, variables U, U', . . ., of sort IRecord, 
variables PR, PR' . . ., of sort PreRecord, and variables UPR, UPR' , . . of sort 
IPreRecord. 

In MSOS a rule defining the semantics of a feature / has the general form, 

Ml , Un / j 

Vl > V\ ■■■ V n > V n cnd /o-v 

f{ti,...,t n ) t ' 

where f(t\, . . . , t n ), t' , and the v[ are program expressions (which can involve 
values), u,u\, . . . ,u n are record expressions, and end is a side condition involving 
equations and perhaps predicates. The key idea is that matching of such MSOS 
rules uses record inheritance. Our concrete notation is similar to a record-pattern 
notational variant for MSOS mentioned in passing in [22]. For example, rule 
[10] in [19] Appendix B could be expressed in our notational variant of MSOS 
as follows: 

^ V 1 (4) 

{st:<r,st :cr ,UPR} 

I := y — > noop 

A definitive MSOS specification S has rules of the form (3), but must also 
specify: (i) the syntax of programs in the language C of interest, and (ii) the 
semantic entities used in the different record components. We choose member- 
ship equational logic to specify (i) and (ii). Therefore, in what follows we assume 
that an MSOS specification is in essence equivalent to a triple ( E,E,R ), with 
(£, E) a membership equational theory containing abstract sorts Program and 
Component, and importing the above-sketched extension of the RECORD specifi- 
cation as a subtheory, and with no other operations in E having kinds in the 
RECORD extension as arguments, except for the [Component] kind. The rules R 
are then MSOS rules of the general form (3), where f{t\, . . ., t n ),t', and the Vi, v\ 
are terms of sort Program, u, u\, . . . ,u n are expressions of sort Record, and end 
is a conjunction of equations and memberships. Furthermore, we assume that 
all MSOS rules in R are in the following normal form 2 : (i) the side condition 

1 A somewhat subtle point explained in what follows is that to organize the compu- 
tations themselves as a category we need some more structure on the objects. 

2 This assumption does not seem overly restrictive in practice; a detailed characteri- 
zation of the class of normalizable MSOS rules should be developed. 
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end does not involve any record, field, index, or [Truth.] (different from [Bool] ) 
expressions in its terms or subterms; and (ii) a record expression appearing in 
either the premisses or the conclusion is either: (1) a variable of the general form 
X, or U; or (2) a constructor term of the general form {i\ : w\, . . . , i n : w n , PR}, 
or { : u>i, ...,«„ : iv n , UPR}, with n > 0, some of the indices perhaps primed, 
and the Wj terms with sorts in the corresponding field components. For example, 
rule [9] in [19] Appendix B might be expressed as the MSOS rule 

U = {env : p, UPR} v = p(x ) 



which fails to satisfy (i) above, but we have an equivalent normal form 



v = p(x ) 



{env.p, UPR } 

X > V 



( 5 ) 



The desired translation is a mapping r : ( E,E,R ) i— > (S' , E' , (/), R') where: 

1. (E',E') is obtained from (E,E) by: (i) omitting all the primed indices and 
their related equations and memberships from the record subspecification 
(but adding the unprimed version of each write-only index); (ii) defining 
subsorts ROPreRecord, RWPreRecord, and WOPreRecord (all containing the 
constant null) of the PreRecord sort, corresponding to those parts of the 
record involving read-only, read- write, and write-only fields (we use variables 
A, A', . . ., B, B' , . . ., and C , C' , . . ., to range over those respective subsorts); 
(iii) In WOPreRecord we also equationally axiomatize a prefix predicate C, 
where C C C means that for each write-only field k the string C.k is a 
(possibly identical) prefix of the string C' .k\ and (iv) adding the signature 
of the module RCONF; 

2. (j> declares all operators in E' as unfrozen; and 

3. R' contains the step rule in RCONF, as well as for each MSOS rule in R , in 
the normal form described above, a corresponding rewrite rule of the form, 



{f{ h ,...,t n ),u pre }—^[t',u post } 

if { VlJ «r e } — ► K,«r*] a ... a K,«r}^K,< ost ] a end', 



where for each record expression u in the MSOS rule, u pre and u post are defined 
as follows. For u a record expression of the general form X or {Pi?}, u pre is a 
record expression of the form {A, B , C}, and u post has the form {A, B' , C'}. For 
u a record expression of the general form U or { UPR}, u pre is of the general 
form R or {PR}, and u pre = u post . Otherwise, for u of the general form {?'i : 
w\, ..., i n : w n , PR}, with n > 1, u pre and u post are record expressions similar 
to u where: (i) if a read-only field expression i : w appears in u, then it appears 
in both u pre and u post ; (ii) if a write-only field expression i' : w appears in u, 
if u labels the conclusion, then u pre contains a field expression of the form i : l, 
with l a new list variable in the corresponding data type, and u post contains 
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a field expression of the form i : l.w (if u labels a condition, u pre contains 
i : nil, and u post contains i : w); (iii) if a read- write pair of field expressions 
i : w,i' : w' appear in u, then u pre contains i : w, and u post contains i : «/; 
and (iv) PR is translated in u pre as A,B,C, and in u post as A,B',C'. Finally, 
if u is of the general form {zi : wi, . . . ,i n '■ w n , UPR }, with n > 1. Then u pre 
and u post are record expressions like u where cases (i)-(iii) as handled as before, 
and (iv) UPR. is translated in both u pre and u post as PR. Furthermore, the 
condition end! is either end itself, or is obtained by conjoining to end the prefix 
predicate C C C' in case subexpressions of the form A, B , C, and A, B', C' were 
introduced in the terms u pre and u post in the conclusion. We assume throughout 
some reasonable naming conventions, such as using different translated names 
for different variables, introducing the same new names for repeated variables, 
avoiding variable capture, and so on. 

For example, the MSOS rule (4) would be translated as the conditional 
rewrite rule: 

{l := v, {(st : a), PP}} — > [noop, {(si : a), PR}] if <j' = a[l i— > u]. 

The translation r just defined is semantics-preserving in a very strong sense. To 
make this clear, we need to discuss the semantic models associated to (finite) 
computations in both formalisms. We shall focus on transitions involving ground 
terms t, t' of sort Program, and with u a ground record expression. First of all, 
note that an MSOS specification S defines a category C s of finite computations, 
whose arrows have the form (f, u) — > ( t',u '), where u = dom{w ), and u' = 
codfw ) are the source and target identity records of the label w, and for some 
n > 0 there are n composable transitions (i.e., their labels are composable) 
derivable from S , 

, Wl . . Wn 

i > 61 , . . . In— 1 * ^ 

such that w = wi ;...;w n . Note that the objects of Cs must be pairs (t,u), 
whose identity arrow is u, since without the second component the identities 
of Cs would be under determined. By considering the labeled subgraph of Cs 
determined by the computations corresponding to one-step transitions we obtain 
a labeled transition system, 3 that we denote L$. 

In rewriting logic, the simplest model associated to a rewrite theory 1Z is its 
initial reachability modelT Reach ^ [6], which defines the 7\l-reachability relation 
[f] — > \t'] between equivalence classes 4 of ground terms modulo the equations in 
1Z by the equivalence, [t] — > [t'\ 1Z b t — > t' . In particular, for 1Z = t(S), 
we can restrict this model to the sort Conf and, because of the (Transitivity) 
and (Reflexivity) inference rules, we then get a preorder relation on equivalence 
classes of Conf ground terms modulo the equations E' in t(S), that is, a preorder 
category Tfleocft.(r( 5 ))|conf • As pointed out in Section 3.1, we will have a t(S)- 
reachability relation (v,w) — > (v',w') iff for some n > 0, there is a sequence 

3 Note that this is a more detailed labeled transition system than the one associated 
to S in [22], since the states are pairs (t,u). 

4 To keep the notation lighter, in what follows we will often leave implicit the equiva- 
lence class notation, and will denote reachability using representative terms. 
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of rewrite steps, each obtained by application of the (Nested Replacement) 
inference rule to the step rule, and by (Equality). Any such application of the 
step rule exactly mimics a one-step rewrite with a rule r' G R! , which is the 
translation of an MSOS rule r € R in S. The semantics-preserving nature of r 
takes the form of a functor tt : T^ eoc ^( T ( l 5 p | Con f — > Cs surjective on objects and 
arrows and defined on arrows by: 

tt : (( t,w ) — » {t',w')) 1 ^ ((t,p(u 0) (, t',p(w '))) 

where the function p maps each record w without primed indices in (17', E') to an 
identity record p(w ) in (A, E) by leaving all read-only fields untouched, adding 
a primed copy of each read- write index (with same value), and making all write 
only fields primed and all with value nil; and where the label w 1 — > w' is defined 
as follows. For a read-only index i, w, w' , and w 1 — > w' all agree on the field i : x; 
for a write-only index i, if w contains the field i : l, then w' will contain a field of 
the form i : l.V , and w 1 — > w' contains the held i' : l ' ; for a read-write index i, if w 
contains the held i : x, and w' the held i : y, then w 1— > w' contains the helds i : x 
and i' : y. The well-dehnedness of this functor follows by induction on the length 
of the rewrites/computations from the strong bisimulation result for one-step 
rewrites stated below. Furthermore, it also requires showing the well-dehnedness 
of the operation w 1 — > w' . This follows easily by induction on the length of the 
rewrites from the following lemma, which is itself an easy consequence of the 
definition of u pre and u post in the translation r: 

Lemma 1. In any one-step rewrite ( t,w ) — > ( t',w '), the record w' has the 
same read-only fields as w, and the value of any write-only field in w is a prefix 
of the corresponding value in w' . 

We can associate to t(S ) the labeled transition system LJ , whose 

transitions are of the form (t,w) ft' ,w'), where (t,w) — > ( t',w ') is a one- 
step r(<S)-rewrite. The semantics-preserving nature of r can be further expressed 
by the following theorem (a proof sketch is given in [19], Appendix C): 

Theorem 1 . (Strong Bisimulation). The projection function tt : (t,w) i— > 
(' t, p(w )), together with its inverse relation 7 r , define a strong bisimulation 
of labeled transition systems tt : LI — > L5 . 

5 Concluding Remarks 

We have presented a general method to make semantic definitions of program- 
ming languages both modular and executable in rewriting logic. It would be 
natural to extend these techniques in the direction of “true concurrency.” The 
point is that SOS provides an interleaving semantics, based on labeled transi- 
tion systems, whereas rewriting logic provides a “true concurrency” semantics, 
in which many rewrites can happen concurrently. This is one of the reasons for 
a gradual shift towards so-called reduction semantics for concurrent languages, 
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which is a special case of rewriting semantics. Although an interleaving semantics 
remains a possible choice, the SOS idea of executing a single program becomes 
less natural when languages are concurrent or even mobile. 

We have also discussed the relationship to MSOS. Once implemented, our 
translation from MSOS to rewriting logic would make available in a sound and 
simple way the possibility of executing MSOS specifications in Maude. As already 
done for a previous translation [2], this can be the basis of a Maude-based tool to 
execute MSOS specifications. Since Maude has breadth-first search, an efficient 
LTL model checker [8], and several other formal tools [9, 15], MSOS specifications 
can then be formally analyzed in various ways. Besides the example in [19], 
we have developed several variants of a modular rewriting semantics for CCS 
and for the be language in [5]. More work on the MSOS translation and on 
experimentation remains ahead. 
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Abstract. Modal Kleene algebra is Kleene algebra enriched by forward 
and backward box and diamond operators. We formalize the symme- 
tries of these operators as Galois connections and dualities. We study 
their properties in the associated semirings of operators. Modal Kleene 
algebra provides a unifying semantics for various program calculi and en- 
hances efficient cross-theory reasoning in this class, often in a very concise 
state-free style. This claim is supported by novel algebraic soundness and 
completeness proofs for Hoare logic. 



1 Introduction 

Complex hardware and software development usually depends on many differ- 
ent models and formalisms. This calls for a unifying semantics and for calculi 
that enhance safe cross-theory reasoning. During the last decade, variants of 
Kleene algebra (KA) have emerged as foundational structures with widespread 
applications in computer science ranging from program and protocol analysis [3, 
12,22], program development [2,18] and compiler optimization [14] to rewriting 
theory [20] and concurrency control [3]. The development has been initialized 
by two seminal papers by Kozen, the first one providing a particularly useful 
and elegant axiomatization of KA as the algebra of regular events [11], the sec- 
ond one extending KA to Kleene algebra with tests (KAT) for modeling the 
usual constructs of sequential programming [12]. But although KAT subsumes 
propositional Hoare logic (PHL) [13], it seems not appropriate as a unifying core 
calculus, since it does not admit an explicit definition of modalities as they occur 
in many popular methods. 

KAT has recently been enriched by simple equational axioms for abstract 
domain and codomain operations [4]. This Kleene algebra with domain (KAD) 
is more expressive than KAT. It does not only allow relational reasoning about 
hardware and software [4], it also subsumes propositional dynamic logic and 
supplies it with a natural algebraic semantics [7]. 

This motivates the following question: Is KAD suitable as a calculus for cross- 
theory reasoning and as a unifying semantics? Answering this question, however, 
requires further consideration of the modal aspects of KAD in general and its 
semantical impact for Hoare logic in particular 1 . 

* Supported by DFG Project InopSys (Interoperability of System Calculi). 

1 The relation between KAD and temporal logics will be the subject of another paper. 



C. Rattray et al. (Eds.): AMAST 2004, LNCS 3116, pp. 379-393, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 
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Our Contributions. First, we use the abstract image and preimage operations 
of KAD for defining forward and backward box and diamond operators as modal 
operators a la Jonsson and Tarski [10]. We show that these operators are related 
by two fundamental symmetries: Galois connections and dualities. The former 
serve as theorem generators, yielding a number of modal properties for free. The 
latter serve as theorem transformers, passing properties of one modal operator 
automatically to its relatives. We also develop further natural and interesting 
algebraic properties, including continuity of domain and codomain. Most of them 
immediately transfer to predicate transformer algebras. 

Second, we study the algebra of modal operators over KAD, which under 
suitable conditions is again a Kleene algebra. This abstraction supports even 
more concise state- free modal reasoning and leads to further structural insight. 

Third, we apply modal Kleene algebra by giving purely calculational algebraic 
proofs of soundness and relative completeness for PHL. We use this formalism 
both for a faithful encoding of Hoare’s syntax and for modeling the standard 
weakest liberal precondition semantics. Our encoding and soundness proof - all 
inference rules of PHL are theorems in KAD is more direct and concise than 
previous KAT-based ones [13]. In particular, when abstracted to the algebra 
of modal operators, the Hoare rules immediately reflect natural properties. Our 
novel algebraic proof of relative completeness is much shorter and more abstract, 
thus applicable to more models, than the standard ones (e.g. [1]). It exploits a 
Galois connection between forward boxes and backward diamonds that is beyond 
the expressiveness of most related modal formalisms. 

These technical results support our claim that KAD may serve both as a 
calculus for cross-theory reasoning with various calculi for imperative programs 
and state transition systems and as a unifying semantics for modal, relational 
and further algebraic approaches. The economy of concepts in Kleene algebra 
imposes a discipline of thought which usually leads to simpler and more per- 
spicuous proofs and to a larger class of application models than with alternative 
approaches, for instance relational algebra (cf. [19]) or temporal algebra [21], 
where some of our issues have also been treated. This is also interesting from a 
pedagogical point of view, since taxonomic knowledge about various structures 
and complex axiomatizations can be replaced by systematic knowledge about a 
few simple operations together with symmetries and abstraction techniques, a 
particular advantage of the algebraic approach. Finally, our results are of inde- 
pendent interest for the foundations of modalities. 

In this extended abstract, we can only describe the main ideas of our ap- 
proach. See [17] for a full technical treatment and [5] for a synopsis of related 
results on modal Kleene algebra and for further support for our claims. 

Outline. The remainder is organized as follows: Section 2 introduces KAD and 
its basic properties. Section 3 introduces modal operators and the associated 
algebras of modal operators. Section 4 develops the basic calculus of modal 
operators. The syntax and semantics of Hoare logic and its soundness and com- 
pleteness proofs in KAD are the subject of Section 5, Section 6 and Section 7. 
Section 8 contains a summary, a discussion of further results and an outlook. 
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2 Kleene Algebra with Domain 

A Kleene algebra [11] is a structure (if, 0, 1) such that (If, +,-,0,1) is 

an (additively) idempotent semiring (an i-semiring) and * is a unary operation 
axiomatized by the identities and quasi-identities 

l + aa*<a*, (*-l) b + ac < c => a*b < c, (*-3) 

1 + a* a < a* , (*-2) b + ca < c => ba* < c, (*-4) 

for all a,b,c £ K (the operation • is omitted here and in the sequel). If the 
structure satisfies (*-l), (*-2) and (*-3), but not necessarily (*-4), we call it a 
left Kleene algebra. It is called a right Kleene algebra, if (*-l), (*-2) and (*-4), 
but not necessarily (*-3) holds. The natural ordering < on K is defined by a < b 
iff a + b = b. Models of Kleene algebra are relations under set union, relational 
composition and reflexive transitive closure, sets of regular languages (regular 
events) over some finite alphabet under the regular operations or programs under 
non-deterministic choice, sequential composition and finite iteration. 

A Boolean algebra is a complemented distributive lattice. By overloading, we 
usually write + and • also for the Boolean join and meet operation and use 0 
and 1 for the least and greatest elements of the lattice. The symbol — denotes 
the operation of complementation. We will consistently use the letters a,b,c. . . 
for Kleenean elements and p,q,r, . . . for Boolean elements. 

A Kleene algebra with tests [12] is a two-sorted structure (If, B ), where K is 
a Kleene algebra and B C K is a Boolean algebra such that the B operations 
coincide with the restrictions of the K operations to B. In particular, p < 1 for all 
p £ B. In general, B is only a subalgebra of the subalgebra of all elements below 
1 in K, since elements of the latter need not be multiplicatively idempotent. We 
call elements of B tests and write test(If) instead of B. All p £ test (if) satisfy 
p* = 1. The class of Kleene algebras with tests is denoted by KAT. 

When a Kleenean element a describes an action or abstract program and a 
test p a proposition or assertion, the product pa describes a restricted program 
that executes a when the starting state satisfies assertion p and aborts other- 
wise. Dually, ap describes a restriction of a in its possible result states. We now 
introduce an abstract domain operator that assigns to a the test that describes 
precisely its enabling states. 

A Kleene algebra with domain [4] is a structure ( K,S ), where K £ KAT and 
the domain operation S : K — ^ test (if) satisfies for all a, b £ if and p £ test (if) 

a < S(a)a, (dl) 5{pa)<p, (d2) S(aS(b)) < S(ab). (d3) 

KAD denotes the class of Kleene algebras with domain. 

Let us explain these axioms. Since 6(a) < 1 by 6 (a ) £ test(if), isotonicity 
of multiplication shows that (dl) can be strengthened to an equality expressing 
that restriction to the full domain is no restriction at all. Axiom (dl) means 
that after restriction the remaining domain must satisfy the restricting test. (d3) 
states that the domain of ab is not determined by the inner structure of b or its 
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codomain; information about < 5(b) in interaction with a suffices. It also ensures 
that the modal operators introduced below distribute through multiplication. 
Moreover, (dl) is equivalent to one implication in each of the statements 

5(a) <p^a< pa, (lip) 8(a) < p <=> ~<pa < 0, (gla) 

that constitute elimination laws for 8, while (d2) is equivalent to the other impli- 
cations. (lip) says that 8(a) is the least left preserver of a. (gla) says that -*8(a) 
is the greatest left annihilator of a. 

All domain axioms hold in the relational model, but (dl) and (d2) suffice 
for many applications, such as, for instance, proving soundness of propositional 
Hoare logic. Our completeness proof, however, depends on (d3). We will always 
explicitly mention where (d3) has to be used. 

Because of (lip), domain is uniquely characterised by the two domain axioms. 
Moreover, if test(A") is complete then a domain operation always exists. If test(A") 
is not complete, this need not be the case. 

Many natural properties follow from the axioms. Domain is fully strict (5(a) = 
0 <t=> a = 0), stable on tests (8(p) = p) and satisfies the import/export law 
(8(pa) =pS(a)). See [4] for further information. 

Moreover, the Galois-like characterization (lip) implies that the domain op- 
eration satisfies a continuity property. 

Proposition 2.1. Domain commutes with all existing suprema in KAD; in par- 
ticular, it is additive (8 (a + b) = 8(a) + 8(b) ) and isotone (a < b => 5(a) < 8(b) ). 

Proof. Let b = sup(a : a £ A) exist for some set A C K. We must show that 
8(b) = sup(5(a) : a £ A). First, by isotonicity of domain, 8(b) is an upper bound 
of the set 5(A) = {5(a) : a € A}, since b is an upper bound of A. 

To show that 8(b) is the least upper bound of 5(A), let p be an arbitrary 
upper bound of 5(A). Then for all a € A, 5(a) < p ■?=> a < pa => a < pb, by 
(lip) . Hence pb is an upper bound of A and therefore b < pb. But by (lip) this is 
equivalent to 8(b) < p. □ 

A codomain operation p can easily be axiomatized as a domain operation on 
the opposite semiring. As usual in algebra, opposition just swaps the order of 
multiplication. An alternative definition uses the operation of converse, which 
can be axiomatized for K £ KA as follows. For all a,b,p £ K with p < 1, 

a°° = a, (a + b)° = a° + b°, (ab)° = b°a°, (a*)° = (a°)*, p° < p. 

Consequently, p° = p and a < b <G> a° < b°. Codomain is defined by p(a) = 5(a°). 

3 Modalities 

We now define various modal operators in KAD. Their names are justified, since 
they induce mappings on test algebras that form Boolean algebras with operators 
in the sense of Jonsson and Tarski. They can also be interpreted, respectively, 
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as disjunctive or conjunctive predicate transformers. This links KAD with the 
syntax and semantics of Hoare logic. 

The first definition introduces forward and backward diamond operators in 
the standard way via abstract preimage and image. 

| a)p=5(ap), (1) (■ a\p = p(pa ). (2) 

Conversely therefore, 5(a) = |a)l and p(a) = (a|l. Forward and backward dia- 
monds are duals with respect to converse. 

\a)p=(a°\p, (a\p = \a°)p. (3) 

They are also related by an exchange law. 

Lemma 3.1. Let K £ KAD. For all a £ K and p,q £ test (K), 

\a)p < ~^q (a\q < ->p. (4) 

Proof. Expanding the definitions of forward and backward diamonds and using 
(gla) we calculate \a)p < <t=> qap < 0 <t=> (a\q < ~>p. □ 

Therefore, even in absence of converse, forward and backward diamond are in- 
terdefinable. Moreover, both operators are unique. Duality with respect to com- 
plementation transforms diamonds into boxes: 

\a\p = ->|a)->p, [a\p= ~<(a\^p. (5) 

By (4) and (5), this symmetry can also be expressed by Galois connections. 

Lemma 3.2. Let K £ KAD. For all a £ K, the operators |a), (a| and (a|, | a] 
are lower and upper adjoints of Galois connections. For all p,q £ test(A^), 

\a)p < q^p < [a\q, (a\p < q p < \a\q. (6) 

Exploiting the symmetries further yields the dualities |a]p = \a°\p and [a\p = 

| a°]p and the exchange law |a]p < ~^q <t=> [a\q < -> p. In later sections, we will 
use these Galois connections as theorem generators and the dualities as theorem 
transformers. We write (a)p and and [a\p if the direction does not matter. 

Many modal properties can be expressed and calculated more succinctly in 
a point-free style in the operator semirings induced by the modal operators. 
While such structure-preserving abstractions are standard in algebra, they have 
no immediate logical analogues. See [17] for more information. 

Proposition 3.3. Let ( K ) he the set of all mappings Xx.(a)x on some K £ 
KAD, where a £ K. Defining addition and multiplication on ( K ) by 

((a) + ( b))(p ) = (a)p+ ( b)p , (7) ((a) ■ (b))(p) = (a)((b)p), (8) 



the structure (( K ), +, (0), (1)) is an i-semiring. Depending on whether (.) is |.) 

or (. \, we call it the forward diamond semiring or backward diamond semiring. 
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The natural ordering on ( K ) is defined by point-wise lifting as 

(a) < (b) <G> \/p.(a)p < ( b)p . (9) 

By duality with respect to complementation, also the structures {[K\, n, •, [0], [1]) 
are i-semirings, the forward and backward box semiring , respectively. Here, n is 
the lower bound operation on box operators defined by 

([o]n[6])(p) = ([a]p)([6]p); (10) 

the natural ordering is lifted as for diamonds. This yields an interesting corre- 
spondence with disjunctive and conjunctive predicate transformer algebras. 

Using the point-wise lifting we can write formulas like (a) + (b) = ( a + b ) and 
([a] n [b]) = (a + b ) in a point-free style. We will strongly use point-free resoning 
in the following sections. This will yield shorter specifications and simpler and 
more concise proofs. 



4 The Algebra of Modalities 

We now develop the basic laws of an algebra of modal operators in KAD. We 
further investigate their symmetries in terms of Galois connections and of duality 
in order to derive further properties. But since our modal operators are not 
completely characterized by the symmetries, we also present properties that are 
based directly on domain and codomain. See [17] for a more technical discussion. 

Expanding the definitions, we can show the following simple properties of 
the units of the operator semirings. 

Lemma 4.1. Let K £ KAD and p £ test (K). Then (0 )p = 0 = ^[0]p and 
[!] = <!)• 

The Galois connections (6) give us the following two theorems for free. 

Lemma 4.2. Let K £ KAD. For all a £ K, we have the cancellation laws 

|a)[a| < (1) < [a||a), (a||a] < (1) < |a](a|. (11) 

Proposition 4.3. Let K £ KAD and a £ K . Then (a) and [a] commute with 
all existing suprema and infima, respectively. If test(AT) is a complete Boolean 
lattice then (a) is universally disjunctive and [a] is universally conjunctive, that 
is, the operators commute with all suprema and infima, respectively. 

Proof. By Lemma 3.2, boxes and diamonds of KAD are upper and lower adjoints 
of a Galois connection. Then the results follow from general properties. □ 

As special cases we obtain, for all a £ K and p,q £ test (K), 



(a) 0 = 0, 
|a]l = 1 



(a)(p+q) = ( a)p+ ( a)q , 

M ( pq ) = (Mp)(M<?)- 
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Consequently, (test(AT), {(a) : a £ K}) and (test(A'), {[a] : a £ A'}) are Boolean 
algebras with operators in the sense of Jonsson and Tarski [10]. This justifies 
calling our boxes and diamonds modal operators. 

We now collect some further natural algebraic properties of modal operators. 
We restrict our attention to diamonds. Corresponding statements for boxes can 
immediately be inferred by duality. 

Lemma 4.4. Let K £ KAD. For all a,b £ K and p,q £ test(A'), 



a + b) = (a) + ( b ), 


(12) 


a<b=> (a) < (b), 


(15) 


1 ab) < a) 6), 


(13) 


1 paq) = \p)\a)\q), 


(16) 


{ab\ < (b\(a\, 


(14) 


(paq\ = {q\(a\(p\- 


(17) 



The properties (13) and (14) can be proved using (dl) and (d2) only; since we 
additionally have (d3), they even become equalities. Spelling out (12) for box 
yields, for instance, [a + b] = [a] n [6], while (13) yields |a]|6] < |o6]. Moreover, 
boxes are antitonic: a < b implies [6] < [a] . 

The following statements show that a star operation can be defined on a 
semiring of modal operators. 

Proposition 4.5. Let \K) be the forward diamond semiring over K £ KAD. 
Defining a star on | K) by 

I a)* ip) = I a*)p, (18) 

for all a G K and p G test(A') turns | AT) into a left Kleene algebra. 

To see that (*-l)-(*-3) hold in the forward diamond semiring |A'), we use that 
that the identities |1) + |aa*) = |a*) and |1) + |a)|a*) > |a*) have been shown 
in [4], whereas |1) + |a)|a*) = |a*) follows using (d3). Moreover, we have the 
quasi-identity p + |a)<7 < q =$■ \a*)p < q (see again [4]) and therefore also 

l&) + |a)|c) < |c) =>• |a*)|6) < |c). (19) 

For (K\, we obtain a right Kleene algebra by similar arguments. 

In case of a complete test algebra, we obtain a full Kleene algebra. 

Lemma 4.6. Let K £ KAT. Then Xx.p + x on test(A') commutes with all ex- 
isting suprema and Xx.px on test(AT) commutes with all existing infima. 

Proposition 4.7. Let K £ KAD and let test(A") be a complete Boolean lattice. 
Then for all a £ K, the operators (a)* and [a]* exist. Moreover, 

(a)* = sup ((a) 1 : i > 0), [a]* = inf([a]* : i > 0). 

This follows from Proposition 4.3, Lemma 4.6 and Kleene’s fixed-point theorem. 

Proposition 4.8. Let K £ KAD with test(A') a complete Boolean lattice. Then 
the i-semiring \K) can uniquely be extended to a Kleene algebra. 

Instead of calculating with domain and modal operator laws, we can therefore 
calculate many modal properties simply in Kleene algebra at this higher level of 
abstraction (see below). 
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5 Hoare Logic 



We now apply our results to obtain completely calculational algebraic soundness 
and completeness proofs for propositional Hoare logic. We first present the syntax 
and semantics of Hoare logic. 

Let <P be a set of propositions built from a set 77 with the usual Boolean 
connectives. Let If be a set of statements defined by the following grammar 
from a set r of atomic commands. 

£ ::= abort | skip | r \ £ ; £ | if <7 then £ else £ | while <P do £ . 

The basic formulas of Hoare logic are partial correctness assertions (PC As) of 
the form {<p} a {ip}, with (p,ip G <1 (the pre- and postcondition) and a £ £. 

To define a semantics with respect to KAD, let K £ KAD. We assign to each 
propositional variable 7r £ 77 a test [7r] £ test(7v ) and to each atomic command 
7 £ r a Kleenean element [ 7 ] £ K. Moreover, we assign 0 to [abort] and 1 to 
[skip]. The remainder is the usual homomorphic extension. 



[<Mb] = MIb], 


( 20 ) 


hb] = -#]> 


( 21 ) 


fa; 01 = Hi, 


( 22 ) 


[ if (j> then a else 0\ = MH + ^MM. 


(23) 


[ while (p do a] = (MH)*^M- 


(24) 



We follow [13] in defining validity of formulas aud PCAs. |= (p <G> [<(>] = 1, for all 
</> € <7. In particular, \= (p — > ip <G> [0] < [V']- Moreover, 

b {</>} « {b} ^ WH-'W < 0. 

Using (gla) and Boolean algebra, we rewrite this definition more intuitively as 

b {<P} « {b} (HIM < [bl- 

In the relational model of KAD, the expression (HIM denotes the set of 
all states that can be reached from states in [</>] through [a]. Therefore, the 
formula (M I M — lb] is indeed a faithful translation of {</>} a {ip} that, by the 
exchange law of Lemma 3.1, is consistent with the standard wlp-semantics (see 
also Section 7 for further details). 

To shorten notation, we will henceforth confuse syntax and semantics and 
use Kleene algebra notation everywhere. Thus we express validity of a PCA as 



b M « M ^ (a| V < q- 



(25) 
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The Hoare calculus for partial correctness of deterministic sequential pro- 
grams consists of the following inference rules. 



(Abort) 


{p} abort {<?}, 


(Skip) 


M skip {p}, 


(Assignment) 


{p[e/x\} x :=e {p}, 


(Composition) 


M a {q} {q} b {r} 

M a ;b {r} 


(Conditional) 


(p A q} a {r} {~>p A q} b {r} 

{g} if p then a else b {r} 


(While) 


(pAgJa {<?} 

{q} while p do a {->p A q} 


(Weakening) 


Pi-^P {P} a {q} q^ q x 
{M a {q x } 



A rule with premises Pi,- - • ,P n and conclusion P is sound if Pi, . , P n \ = P. 
Derivations are defined in the standard way. 

(Assignment) is a non-propositional inference rule that deals with the internal 
structure of states. We therefore do not encode it directly into our framework, 
but instead use the set T of atomic commands as a parameter in our approach. 
The requirement of sufficient expressiveness on r that ensures completeness of 
the calculus will be discussed in Section 7. Following [13], we call this abstract 
form of Hoare logic propositional Hoare logic (PHL). 

6 Soundness of Propositional Hoare Logic 

We now prove soundness of PHL with respect to the KAD-semantics. More pre- 
cisely, we show that the encoded inference rules of PHL are theorems of KAD. 
This subsumption is a popular exercise for many logics and algebras of programs, 
among them propositional dynamic logic [8] and KAT [13], which are both sub- 
sumed by KAD. However our result is interesting for two reasons, a syntactic and 
a semantic one. First, our encoding of PHL is more simple, abstract and direct, 
and Hoare-style reasoning in KAD is more flexible than in previous approaches. 
However we do not sacrifice algorithmic power. Second, the properties of our 
modal operators defined in terms of abstract image and preimage operations 
reflect precisely those of the standard partial correctness semantics [1, 15] and 
show that KAD provides a natural abstract algebraic semantics for PHL. 

A first point-wise encoding of the soundness conditions for the Hoare rules 
is rather straightforward from (25). (Composition), for instance, becomes 
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This is a theorem of KAD, since 

(ab\p < (b\(a\p < (b\q < r 

by (decomposition). As a second example, (While) becomes 

{a\(pq) <q=> {{pa)*^p\q < ~>pq. 

This is also a theorem of KAD. Using (induction), we calculate 

{a\(pq) <q=> (( pa)*\q <q^ p({(pa)*\q ) < -^pq ^ {{pa)*^p\q < Apq. 

Point-wise encodings and proofs for the remaining PHL-rules are similar. Conse- 
quently, soundness of PHL can be proved literally in one line per inference rule 
from natural properties of KAD. In KAT, (Composition), for instance, must be 
encoded quite indirectly as 

pa < aq A qb < br =>■ pab < abr 



and the proof of tlreoremhood is based on rather syntactic commutation prop- 
erties (cf. [13]). We can obtain this encoding also in KAD, using (lip). More 
generally, (lip) and (gla) provide translations of all PHL-rules into KAT and, 
using a result from [9], connect validity with respect to PHL with PSPACE 
automata-tlreoretic decision procedures. See [17] for a deeper discussion. 

Compared with standard textbooks (cf. [1, 15]), our proof is about ten times 
shorter. In addition, the textbook proofs are only semi-formal, since many logical 
and set-theoretic assumptions are left implicit. A complete formalization would 
produce further overhead. 

We now give another point-free soundness proof of PHL in KAD that is even 
more abstract and concise. In particular, the properties expressed by the Hoare 
rules now correspond to natural algebraic properties of the algebra of modal 
operators. 

Proposition 6.1. Let K £ KAD. Then the soundness conditions for the infer- 
ence rules of PHL can be encoded as follows. For all a,b £ K and p £ test(A'), 



(Abort) 

(Skip) 

( Composition ) 
( Conditional) 
(While) 
(Weakening) 



(0| < <g|, 

<l| < <l|, 

(a6| < (6|(a|, 

(pa + ^pb\ < (a\(p\ + {b\(~^p\, 

( a l(p| < <!| => H?l((pa)*l < hp\, 

(Pi\ < {p\ A (p\(a\ < {q\ A (g| < (q^ => (gi|(a| < (gi|. 



The point-free encoding is derived from the point-wise one using the principle 
of indirect inequality: p < q iff q < r implies p < r for all r. 
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(Skip) and (Abort) now reflect natural or even trivial semiring properties. 
(Conditional) expresses (additivity) and (import/export) of the operator semir- 
ing, (While) expresses a variant of (induction). (Composition) expresses (de- 
composition); it becomes an equality when (d3) is assumed on the underlying 
KAD. (Weakening) is the only rule where at first sight, nothing has be gained by 
the lifting. However, its correctness proof can now be based entirely on semir- 
ing properties, instead of expanding to properties of domain. These facts are 
immediately reflected by the following subsumption result. 

Theorem 6.2. The point-free encodings of the PHL -rules are theorems in KAD. 

Proof. The point-free variants of (Abort) and (Skip) are trivial consequences 
of Lemma 4.1. The point-free variant of (Composition) is nothing but (14). 
The point-free variant of (Conditional) is evident from (12) and (14). (While) 
follows immediately from (19) and isotonicity. (Weakening) holds by isotonicity 
of multiplication in i-semirings. □ 

Theorem 6.3. PHL is sound with respect to the KAD semantics. 

Proof. By induction on the structure of PHL derivations, using Theorem 6.2. □ 

As observed in [13], all Horn clauses built from PCAs in PHL that are valid with 
respect to the standard semantics are theorems of KAT ; whence a fortiori of 
KAD. PHL is too weak to derive all such formulas. Consequently, KAT and KAD 
have not only the derivable, but also the admissible rules of PHL as theorems. 

7 Completeness of Propositional Hoare Logic 

In this section we provide a novel algebraic completeness proof for the inference 
rules of PHL, using modal Kleene algebra as a semantics. Conventional com- 
pleteness proofs use the weakest liberal precondition semantics. For a set S of 
program states, a relational program P C S x S and set T C S of target states 
one defines 

wlp(P, T) = {seS : P(s) C T}, (26) 

where P(s) is the image of s under P. Equivalently, wlp(P, T) is the largest 
subset U C S such that P(U) CT. In a modal setting the wlp-operator can then 
of course be identified with the forward box operator. Confusing again syntax 
and semantics, the Galois connection (6) and (25) immediately imply that 

b M « {<?} P < I a\q. (27) 

On the one hand, this Galois connection connects PHL syntax and semantics in 
a very concise way. One the other hand, we get the entire wlp-calculus for free 
by dualizing our results from Section 4. 

For the standard completeness proofs (see e.g. [1]) it is crucial that the un- 
derlying assertion language is sufficiently expressive. This implies that for all 
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statements a £ £ and all postconditions if £ <P there is an assertion <f> £ <L> that 
expresses the weakest liberal precondition for if under a, i.e., 

M = wl P(M>M)- (28) 

Using (28) we can continue working semantically in KAD. We extend the original 
calculus so that all predicates are denoted by propositional variables. Complete- 
ness of this extension will then imply completeness of the former calculus. 

For every atomic command 7 £ T and test <7 we add an axiom 

{IflM 9 {<?}> (29) 

where g = [ 7 ]. (Assignment) has precisely this form. 

Before the completeness proof, we state some technical properties of boxes 
in connection with conditionals and loops. Logical variants appear in [1], 

Proposition 7.1. Let K £ KAD. Let a,b,c,w £ K and p,q £ test(AT). 



(i) For c = if p then a else b, 
p{\c\q) =p(\a]q), 


(30) 


->p(|c]< 7 ) = ->p(\b\q). 


(31) 


(ii) For w = while q do a, 

p{\w\q) =p\a](\w]q), 


(32) 


~^p{\w]q) < q. 


(33) 



The proofs need a few lines of calculus using the properties from Section 4. Now 
we can proceed, as for instance in [ 1 ], 

Lemma 7.2. Let K £ KAD. For all a £ K that are denotable by PHL commands 
and all q £ test(A'), the PCA {|a]q} a {< 7 } is derivable in PHL. 

Proof. Let h {p} a {< 7 } denote that {p} a {q} is derivable in PHL. The proof is 
by induction on the structure of command a. 

(i) a is either skip or abort or denotes an atomic command. Then the claim is 
trivial, since PHL contains the respective PCA as an axiom. 

(ii) Let a = b and c = be. By the induction hypothesis, 

h{| 6 ](|c]g)} 6 {|c]g}, h{l c]q}c{q}. 

Now (Composition) shows h { 1 6] ( | c] g) } be {< 7 }, which by the additional assump- 
tion of (d3) and the dual of (13) is equivalent to h { 1 6c] g} be {q}. Note that this 
is the only part of the proof where (d3) is used. 

(iii) Let a = if p then b else c. By the induction hypothesis, 

HI b}g}b{q}, \~ {\c\q} c {q}. 

Hence, by (Weakening), also 



h {p{\b]q)} b {<?}, 



h {H 1%)} b M- 
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By (30) and (31) these statements are equivalent to 

h {P(\a]q)} b {<?}, h {^p(\a]q)} c {q}, 
so that (Conditional) shows the claim. 

(iv) Let a = while p do b. Let c = \a]q. By the induction hypothesis, 

h {|a]c} b {c}. 

By (32) this is equivalent to h {pc} b {c}. (While) shows that h {c} a { _i pc} and 
(33) and (Weakening) yield h {|a]q} a {q}, as required, □ 

We are now prepared for the main theorem of this section. 

Theorem 7.3. PHL is relatively complete for the partial correctness semantics 
of deterministic programs in KAD. 

Proof. We must show that |= {p} a {q} implies h {p} a {q}. This follows from 
(27), Lemma 7.2 and (Weakening). □ 

Alternatively, we could also use our encodings of PCAs in KAD in the complete- 
ness proof. We could write (a\\~p < q instead of b {p} a {q} to further stress 
the fact that our proof is entirely in Kleene algebra and to denote that only 
the encodings of PHL-rules are allowed for transforming the indexed diamonds. 
Using this encoding, the statement (a|h(|a]p) < p, or even (a|h|a] < 1 1] , looks 
very much like a cancellation property of a Galois connection. This fact certainly 
deserves further consideration. 



8 Conclusion and Outlook 

We have investigated Kleene algebra with domain as a modal Kleene algebra. 
Modal operators have been defined as abstractions of relational image and preim- 
age operations. Their symmetries have been formalized in terms of Galois con- 
nections and dualities. We have also studied the semirings induced by the modal 
operators. This additional level of abstraction yields very concise state-free spec- 
ifications and proofs of modal properties. 

Our results show the usefulness of modal Kleene algebra both as a calculus 
for cross-theoretic reasoning with various calculi for imperative programs and 
state transition systems, and as a unifying semantics for modal, relational and 
further algebraic approaches. While an analogous claim has already been verified 
for relational approaches [4] and for propositional dynamic logic [7], we provide 
algebraic soundness and completeness proofs for Hoare logic that use modal 
Kleene algebra both at the syntactic and at the semantic side. In particular the 
state-free soundness proof and the completeness proof exhibit very nicely the 
natural algebraic properties that are implicit in the partial correctness assertions 
and Hoare rules. 
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Compared with other formalisms, modal Kleene algebra is also very flexible. 
E.g., in [17], we show that several inference rules that are derivable in PHL are 
theorems of modal Kleene algebra. There, it is not always preferable to reason 
entirely using the modalities. Especially when the rules encode commutativity 
conditions, the subtheory KAT may provide more direct proofs. 

It is also interesting to investigate in how far modalities can be eliminated 
from KAD formulas. In combination with hypothesis elimination techniques, we 
obtain a linear translation of certain KAD-expression into identities over KAT, 
whose validity can be decided by automata in PSPACE [17]. 

Modal Kleene algebra also subsumes Hoare logic for programs with bounded 
nondeterminism. Guarded commands, for instance, can be encoded as 

if Pi -> a x 0 • • • 0 p n -> a n fi = sup (pidi : 1 <i<n), 

dopi — y a\ 0 ' ' ' D Pn ~ * °n od = (sup(pjdj : 1 < i < n))* inf(->pj : 1 < i < n). 

Program termination can also be modelled in modal Kleene algebra [4, 6] . 
This suggests extending our approach to Hoare logics for total correctness. More- 
over, since modal Kleene algebra allows the specification of syntax and relational 
semantics of modal calculi in one single formalism, one can use it to develop a 
calculational modal correspondence theory; see [4, 5, 18] for first results. To fur- 
ther establish modal Kleene algebra as a unifying framework, we also plan to 
consider temporal logics like LTL or CTL; for LTL an account of this along the 
lines of [21] is contained in [5]. Recently, the modal operators have also been 
incorporated into Lazy Kleene Algebra [16], a framework that extends the work 
of Cohen [3] and von Wright [22] and is designed to deal with both terminating 
and non-terminating computations and hence also with reactive systems. It is 
a challenging task to apply the framework of modal Kleene algebra to other 
problems and structures for further extending its practical relevance. 
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Abstract. This paper presents a new rule for reasoning about method 
calls in object-oriented programs. It is an adaptation of Hoare’s rule of 
adaptation to the object-oriented paradigm, which takes both the write 
effects and the creational effects of a method into account. The new rule 
contributes in various ways to the modularity of the specification. We 
also argue that our rule of adaptation is the missing link between Hoare 
logics and proof outlines for object-oriented programs. 



1 Introduction 

It is often argued that encapsulation is one of the strong features of the object- 
oriented paradigm. Encapsulation is obtained by forbidding direct access to the 
internal state of other objects. Thus one can only query or alter the state of an 
object by invoking a method. Therefore method calls are the main computational 
mechanism in object-oriented programs. 

Different calls to a particular method may occur in completely different con- 
texts. Preferably, a method has one fixed pre/post specification that acts as a 
contract between the designer of the method and its clients. This contract should 
enable a client to infer the behavior of a call to this method. Essential for this 
scenario is that the reasoning rule for method calls is able to adapt the method 
specification to the required specification of the call. This can be achieved for 
procedural languages with global variables by means of the rule of adaptation. 
This rule was introduced by Hoare [5], and improved by Olderog [11]. 

The above mentioned rules suffice in a context where only simple global 
variables occur. However, the set of variables of modern object-oriented programs 
is more complex since each existing object has its own internal state. Moreover, 
the state can be extended during the execution of a method by object creations. A 
rule of adaptation for object-oriented programs has to take these state extensions 
into account. 

The main contribution of this paper is a rule of adaptation for object-oriented 
programs. The rule enables in various ways a modular specification of object- 
oriented programs. For example, it results in an important separation of concerns 
for local variables in proof outlines of object-oriented programs. 

The rule that we present in this paper integrates write effects [4], and cre- 
ational effects of a method in a natural way in the programming logic. By the 



C. Rattray et al. (Eds.): AMAST 2004, LNCS 3116, pp. 394-408, 2004. 
(c) Springer- Verlag Berlin Heidelberg 2004 




Modularity and the Rule of Adaptation 395 



creational effects of a method we mean the types of the objects that a method 
creates. These optimizations of the rule also contribute to the modularity of the 
required specification. The integration of write effects ensures that a method 
specification only needs to specify its effect on the fields that actually occur in 
the implementation of the method. Thus one does not have to revise the specifi- 
cation whenever a field is added to a class. The integration of creational effects 
permits method specifications only to report the creation of new objects if their 
implementation actually contains statements that create objects. They need not 
explicitly express their absence. 

Our adaptation rule has been integrated in a tool that computes the verifica- 
tion conditions of proof outlines for a sequential subset of Java. The verification 
conditions are passed to a theorem prover. The tool is a successor of the tool 
described in earlier work [1], The adaptation rule is in particular suitable for 
proof outline logics since it describes the verification condition that results from 
the specification of a call and the corresponding method. Thus it enables a shift 
from Hoare logics (and the embedding and manipulation of Hoare triples in a 
theorem prover) to proof outlines for object-oriented languages. 



2 Related Work 

The past decade has seen a large interest in proof methods for object-oriented 
programming. An enumeration of the results in this area will therefore likely be 
incomplete. Several Hoare logics for sequential object-oriented languages have 
been proposed [14, 10, 6, 15, 13]. 

Kleymann [7] has introduced a new rule of consequence for sequential pro- 
grams. It enables one to adapt the values of logical variables in specifications. The 
outline of the rule resembles the outline of the rule that we propose. However, 
it solves none of the typical object-oriented problems like the state extensions 
that are due to object creation. 

One particular advantage of the adaptation rule we present in this paper is 
its treatment of local variables. The values of the local variables of the caller are 
not changed during a method invocation. A common technique that is used to 
reflect this fact is to allow the use of a substitution rule (see, for example, [14, 
15,13]). Such a rule replaces a logical variable by a local variable in both the 
precondition and the postcondition of a method call: 

{P} call {Q} 

{ P[u/z ]} call {Q[u/z}} 

In this paper we use the convention that u always denotes a local variable. In 
the above rule z is a logical variable. Applying this rule is the only way to prove, 
for example, that the value of a local variable of the caller does not change. 

Example 1. Let ?n(){ skip } be the declaration of method rn with body skip. 
Obviously, the Hoare triple {u = 1} m(); {u = 1} is valid. To prove this we must 
first derive {z = 1} skip {z = 1}. A rule for reasoning about method calls then 
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typically lets us infer {z = 1} m(); {z = 1}. An application of the substitution 
rule with [u/z] then yields the desired specification. Observe that the introduc- 
tion of the logical variable z is necessary because the local variable u is out of 
scope in the body of the method. 

The above example reveals an important drawback of this technique. It turns 
out that to prove a property of the local variables of the caller one has to express 
this property in the proof outline of the procedure in terms of logical variables. 
This clearly violates the modularity of the method specification. Our rule of 
adaptation provides a means to prove such facts by expressing it in the proof 
outline of the caller only. 



3 Object-Oriented Programs 

The rule of adaptation that we propose in this paper is suited for reasoning 
about method calls in object-oriented programs. An adaptation rule has to take 
into account all changes to the program state that can result from execution 
of a method. For this reason it cannot be stated independent of the rest of the 
programming language. Therefore we outline in this section a sequential object- 
oriented Java-like language to which our adaptation rule will be tailored. The 
chosen language illustrates the main features of object-oriented languages. At 
the same time it leaves out some features of Java that would merely complicate 
the definitions. 

The syntax of the programming language is summarized in Fig. 1. A program 
7t consists of a set of classes. The declaration of a class specifies the fields (or 
instance variables) of the class (denoted by the sequence x), and a set of methods. 
A clause extends c! indicates that the class is an extension of another class c! . 
In that case, the class is said to be a subclass of class c! . We assume that a class 
extends the root class Object if the clause is omitted. A class inherits all fields 
and methods of its superclass. We impose no restrictions concerning the fields 
or methods that a class declares in relation to the fields and methods that it 
inherits. That is, we allow both held shadowing and method overriding. 

A method m specifies a sequence of formal parameters u n , a sequence 

of additional local variables v, a statement S and the return value e. For brevity, 
we leave the return type of the method implicit. The formal parameters and 
the sequence v make up the local variables of the method. The scope of a local 
variable is the method to which is belongs. We use u as a typical element of the 
set of local variables of a method. It denotes either a formal parameter or an 
additional local variable from v. 

Assignments are divided in two kinds. Assignments to local variables have 
the form u := e, where e denotes an expression that has no side effects. This 
kind of assignment has no permanent effect on the program state (the values 
of local variables are discarded when the method terminates). Assignments to 
instance variables have the form e.x := e' . Execution of such a statement results 
in the assignment of the value of e! to field x of object e. 
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op £ Op 
y £ Loc 
e £ Expr 



S £ Stat ::= 



meth £ Meth 
class £ Class 
7r £ Prog 



an operator on elements of a primitive type 
= u | e.x 

:= null | this | y | ei = e 2 | (c)e | e instanceof c | ei ? e 2 : e 3 
op(ei, 

y := e | S' ; S' | u := new c() | u := eo.m(ei, . . . , e n ) 

| if (e) { S } else { S } | while (e) { S } 

:= m(ui, . . . , u n ) { v S return e } 
class c (e | extends c) { x meth*} 

= class* 



Fig. 1. The syntax of the programming language 



A statement u := new c() involves the creation of a new object of class c. A 
reference to this new object is assigned to the local variable u. Method invoca- 
tions are denoted by eo-m(ei, . . . , e n ). Here eo is the object of which method m is 
invoked. The expressions ei, . . . , e n are the actual parameters of the invocation. 

The expressions listed are a minimal subset that suffices for our present 
purposes. The instanceof operator is used to handle dynamic binding. An 
expression e instanceof c is true if e denotes an instance of (some subclass 
of) class c. Casts of the form (c)e can be used to cope with held shadowing 
[13]. They change the type of their argument e to c. An expression ei ? 
is a conditional expression. Such expressions are important for reasoning about 
aliases [13]. 

We consider only two primitive types in this paper: int and boolean. Vari- 
ables in the program may also have a reference type. In that case the type of 
the variable is one of the classes declared in the program. We will tacitly assume 
that all programs are well-typed. We refer to the type of an expression e by [e|. 
The variable t. ranges over the set of types. 

Semantics. A complete description of the formal semantics of the presented 
language can be found in the full version of this paper [12]. Here we restrict our 
attention to a formal description of the states of object-oriented programs. This 
enables us to give a formal semantics to method calls in the final part of this 
section. Moreover, it should be helpful for a proper understanding of the rest of 
this paper. 

We start our description with some auxiliary definitions for a program n. 
The program it determines among other things the subclass relation. By c A d 
we denote that c is a subclass of d . This relation is reflexive and transitive. We 
assume that TV (c) denotes the direct superclass of a class c. It is undefined if c 
has no superclass. We say that d is a proper subclass of c if d < c and d ^ c. 

Let Var denote a set of variables. We assume that at least all local variables 
that are used in 7r and the special-purpose variable this are elements of Var. Let 
IVar c denote the set of instance variables declared in class c. Due to inheritance 
an object can have several fields with the same identifier. An expression e.x 
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always corresponds to the first declaration of a instance variable x as found by 
an upward search that starts in class [e|. The upward search is formalized by 
the function origin, which is declared as follows. 

. . , s ( c if x G IVar c 

origin(c,a;) | origin(F^ (C), x) otherwise 

We represent objects as follows. Each object has its own identity and belongs 
to a certain class. Let C be the set of classes declared in 7r. For each class c £ C 
we introduce the infinite set O c = {c} x N of objects of class c (here N denotes 
the set of natural numbers) . 

The domain of a variable of type t is denoted by dom(t). The domains 
dom(boolean) and clom(int) are the set of boolean and integer values, respec- 
tively. Due to subtyping a variable of some reference type c can also refer to an 
object of some subclass of c. Let subs(c) be the set of all subclasses of class c. 
Then dom(c) is the set ((J c £subs ( c ) O c ) U {v}. Here v is the value of null. 

A state (tr, r) of a program 7r consists of a heap a and an environment r. An 
environment t G T assigns values to the local variables. Formally, T is the set 
n^GVar dom( |z|) • Note that by riaeA(^ > ( a )) we mean a (generalized) cartesian 
product. An element of this set is a function that assigns to every element a G A 
an element of the set P(a). 

A heap consists of the existing objects. Each object in turn has its own 
internal state (the values of its instance variables). The internal state of an 
object o G O c is a total function that maps the instance variables of class c 
and its superclass to their values. Let supers(c) be the set {c' G C\c A c'}. The 
internal state of an instance of class c is an element of the set internal(c), which 
is the set 

n n d ° m (N) • 

c G supers (c) xGlVar c 

A heap cr is a partial function that maps each existing object to its internal 
state. That is, cr is an element of the set n cec ( N — *■ internal(c)^ . Note that cr(c) 
is not defined for objects that do not exist in a particular heap cr. Thus a specifies 
the set of existing objects. We will only consider states that are consistent. A 
heap is consistent if all instance variable of existing objects refer to existing 
objects or u. Similarly, an environment is consistent with a heap if all variables 
refer to existing objects or u. 

Expressions are evaluated relative to a program 7 r and a state (cr, t). The value 
of an expression e is denoted by £(e)(cr, r). We leave the program 7r implicit. The 
definition of the function £ can be found in the full paper [12]. 

Method Calls. Our rule of adaptation is designed for reasoning about method 
calls in object-oriented languages. In this section we discuss the structural oper- 
ational semantics of such method calls. By (S, (a, r)) — > (cr ',t') we denote that 
a computation of S that starts in a state (cr, r) ends in a state (cr' , r') . 

Recall that a call to method m of object eo is of the form eo.m(e \, . . . , e n ). 
We assume that all methods are public. This implies that we have to deal with 
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dynamic binding if a method is overridden in a subclass. However, we will first 
describe the case of a method that is not overridden. This implies that we can 
simply lookup the implementation of method m in class [eo| (we ignore method 
overloading). Let this implementation be m(u i, . . . ,u n ){ v S return e }. The 
call starts with the context switch in which the value of eo is assigned to this 
and the values of the actual parameters e = ei, . . . , e n are assigned to the formal 
parameters u = ui, . . . ,u n . The additional local variables v initially have their 
default value. The default value depends on the type of the variable. We assume 
that def(t) denotes the default value of type t. After execution of the body the 
value of e is assigned to u. These steps are described by the following rule. 

(S, (t T,Ti)) -> (cr',T') 

Ti = r[this, u, v !-> £(e 0 )(er, r),£(e)(a, t), def ([«[)] 

t' = t[u i— > £(e)(g', t')] 

(u := e 0 .m(ei, . . . , e n ), (a, t)) -> (a 1 , t') 

Observe that the environment t' only differs from r in the value that is 
assigned to u. All other local variables are not changed by the method call. On 
the other hand, the fields of the objects in cr may have different values in a'. 
Moreover, the heap cr' possibly contains objects that did not exist in cr. 

Evaluation of calls to public methods requires an evaluation of eo to deter- 
mine to which implementation the call is bound. Let £(eo)(a, t) = (c, n). Then 
this call is bound to the implementation of method m that is found in class c 
or otherwise the first implementation of this method in a superclass of c. In all 
other aspects the evaluation of the call is similar to the rule above. 

4 The Assertion Language 

The proof rule that we propose is tailored to a specific assertion language called 
AsO (Assertion language for Object structures). We will describe the syntax and 
semantics of AsO in this section. Moreover, we will explain some of the design 
decisions behind the language. 

Any Hoare logic is tailored to a specific assertion language in which the as- 
sertions are expressed. The assertion language decides the abstraction level of 
the logic. An important design decision behind AsO is to keep its abstraction 
level as close as possible to the programming language. In other words, we re- 
frain as much as possible from introducing constructs that do not occur in the 
programming language. This makes it easier for programmers to annotate their 
programs. 

The set of expressions in AsO is obtained by extending the set of program 
expressions with the following clauses. 

I £ LExpr ::= ... j z \ l[l'\ \ /.length. 

The variable z denotes a logical variable. A logical variable is simply a place- 
holder for an arbitrary value. Logical variables are, for example, used to refer to 
the old values of variables in the postcondition of a method. 
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The only real additions are the two operations on finite sequences. We allow 
logical variables of type t* for some type t of the programming language. This 
means that its value is a finite sequence of elements from the domain of t. Finite 
sequences can be used to specify properties of object structures. For example, 
they enable us to express that there exists a sequence of objects in which each 
objects has a pointer to its successor in the sequence. In fact, finite sequences 
are also essential for our adaptation rule as will become clear in the rest of this 
paper. We write l[l') to select the element at position l 1 in the sequence l. The 
length of a sequence l is denoted by /.length. 

Formulas in AsO are built from expressions in the usual way. 

P,Q € Ass ::= l\ = I 2 \ ~^P \P A Q \ 3z : t{P) 

A formula 3z : c(P) means that P holds for an existing object of (a subclass of) 
class c or null. A formula 3 z : c*(P) indicates that P holds for a sequence of 
such objects. A formal definition of the semantics of AsO can also be found in 
the full paper [12]. We sometimes omit the type in 3 z : f(P) if it is clear from 
the context. 

The standard abbreviations like pV q for -i(->p A ~^q) and Vz(P) for ^3^^(P) 
are valid. We also use two other useful abbreviations. A formula z £ z 1 will 
stand for 3/(0 <i< z' . length A z = z'[Z]), and z C z' abbreviates the formula 
VZ(0 < i < z. length — > z[i\ G z'). 

Note that the validity of assertions may also be affected by the creation of new 
objects. We can, for example, express in the assertion language that there exist 
no objects of some class c by means of the formula Vz : c(z = null). This formula 
clearly does not hold in the state that results from executing u new c(). 

5 The Effects of a Method 

The rule of adaptation that we present in the next section integrates write effects 
[4] in a natural way in the verification conditions of method calls. Write effects 
specify what variables are altered by a method. Thus they implicitly contain 
information about which variables remain unchanged by a method. We approxi- 
mate the set of variables that is written by a method in the sense that we do not 
attempt to solve the aliasing problem in write effects. We only analyze which 
fields are possibly assigned. 

Similarly, one can statically collect information about which objects are pos- 
sibly created by a class. We will call this information the creational effects of 
a method. These effects can be used to guarantee that a method creates no 
objects of a particular class. The creation of objects can affect the validity of 
assertions as explained in Sect. 4. Surprisingly, a specification language for Java 
such as JML [8] seems to have no clause that enables the designer of a method 
to specify its creational effects. The adaptation rule in this paper reveals that 
such information is equally important as the well-known frame conditions. 

By the effects of a method we mean a pair that consists of the creational 
effects and the write effects of the method. The creational effects of a method 
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is the set of classes of which objects are possibly created by the method. The 
write effects is the set of fields that are possibly assigned by the method. A field 
is described by a pair that consists of the class in which the field is declared and 
its identifier. We denote effects by tp or by its pair of constituents (cs,fs). In the 
rest of this section we give a formal definition of the effects of a method. 

The effects of a method implementation meth are given by sef (meth) (ms) . 
The second parameter is the set of methods that have already been considered. 
This parameter prevents a circular definition in case of recursive methods. The 
effects of a method implementation in some class c are the effects of its body. 
Let meth = m(u \, . . . , u n ){ v S return e }. Then 



sef (meth) (ms) 



sef(S) (ms U {(c, m)}) if (c, m) ^ ms 
(0, 0) otherwise . 



The following cases list the effects of basic statements. 



sef(u := e)(ms) 
sef(e.x := e , )(ms) 
sef (Si ; S 2 )(ms) 
sef (u := new c())(ms) 
sef(if (e) { Si } else { S 2 })(ms) 
sef (while (e) { S })(ms) 



( 0 , 0 ) 

(0, {(origin(|e|, x), x)}) 
sef(Si)(ms) U sef (S 2 )(ms) 

(M,0) 

sef(Si)(ms) U sef (S 2 )(ms) 
sef (S) (ms) 



The union of two effects is defined as follows: 



(cs 1 ,fs 1 ) U ( cs 2 Js 2 ) = (csi U cs 2 ,fs i U fs 2 ) . 



Finally, we will define sef(u = eo.m(ei, . . . , e n ))(ms). Due to dynamic bind- 
ing we cannot (in general) statically decide which implementation will be bound 
to this call. Therefore we consider all possibilities. We denote the set of classes 
that provide an implementation for this call by impls([eo|, to). More precisely, 
impls(c, m) denotes the set of classes that contains 

— class c if it provides an implementation of method m or otherwise the class 
from which c inherits the implementation of method m; 

— All subclasses of class c that provide an implementation of method m. 

Let impl(c, m) denote the implementation of method m in class c. The definition 
of the final clause is then as follows. 



sef(u := e 0 .m(ei,...,e n ))(ms) = |J 



c6impls(Ie 0 I,m) 



(sef(impl(c, m))(ms)) 



6 A Rule of Adaptation for OO 

The Starting Point. The rule of adaptation that we propose in this paper was 
inspired by the profound analysis by Olderog of several earlier rules of adaptation 
[11]. Olderog showed that the precondition of Hoare’s original proposal was not 
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the weakest possible precondition that fits in the adaptation rule. He described a 
way to actually derive a weaker precondition. His analysis also leads in a similar 
way to a rule of adaptation that is based on the strongest possible postcondition. 
This particular rule appears also in [16]. It has the following form. 

insm 

P[y/x\ A \/z(P'[y/x) -> Q') -► Q 

{P}S{Q} 1 j 

Here y denotes a sequence of fresh logical variables (not occurring free in P, 
P' , Q or Q'). The sequence x contains all program variables that occur in the 
statement S, and z is a list of the logical variables that occur free in P' or Q' . 

The logical variables in y are placeholders of the values of the program vari- 
ables x in the initial state. The antecedent of the verification condition of this 
rule says that P holds in the initial state. Typically, this implies that P' also 
holds in the old state for particular values of its logical variables. For those val- 
ues of the logical variables we then infer that Q' holds in the final state. And Q' 
must in turn imply Q. 

One particular advantage of this adaptation rule is that it considers the old 
values of the variables (in the state preceding the call) instead of the new values 
after the call. This is important due to the state extensions in object-oriented 
programs. In the precondition variant we are forced to reason about objects 
that do not (yet) exist. But our assertion language only describes properties of 
existing objects. A postcondition variant of the adaptation rule only requires us 
to consider the objects that existed in the initial state from the perspective of 
the final state. That boils down to reasoning about subsets of the objects that 
exist in the state after the call. 



Modelling the Old Heap. To design an object-oriented variant of the above 
adaptation rule we have to analyze which parts of the state are modified by a 
method call. Recall from Sect. 3 that the environment of the caller (and hence 
every local variable of the caller) does not change during a method call. Therefore 
we do not have to distinguish between the old values of local variables of the 
caller and their new values. The heap however may change in two ways. We have 
to deal with both heap modifications and heap extensions. 

Observe that the above rule introduces a sequence of logical variables y that 
represent the old values of the program variables. A first challenge for an object- 
oriented version of the rule of adaptation is to introduce logical variables that 
model the old heap. The heap comprises the existing objects and the values of 
their instance variables. We can model the old heap by means of a fresh logical 
variable y of type Object*. We will assume that this sequence contains the 
objects that existed in the old heap. 

The internal state of an object consists of the values of its instance variables. 
For each instance variable x of some type t defined in some class c we introduce a 
fresh logical variable y(x c ) of type t*. The idea is that if an object o is stored at 
position i in the sequence y then the value of o.x is y(x c )[i\. This straightforward 
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model of the old heap presupposes that we have some way of finding the index 
of an object in the old heap. For this purpose we introduce a function f that 
yields the index in the old heap of every object. 

This model of the old heap is based on the following assumptions. 

— Mz : ObjectV?'(0 < i < /u. length A z = fj,[i] — > f (z) = *), 

which states that the index function yields the index of each object in /i; It 
also implies that each object occurs at most once in the old heap; 

- M^c) Q Ah 

for every field x declared in some class c such that |x[ € C. This formula 
boils down to consistency of the old heap. 

We denote the conjunction of these two assumptions by heap(/Z, f). This for- 
mula should be available in the theorem prover as an axiom for the verification 
conditions. 



Bounded Quantification. An important concept in our rule of adaptation is 
that of bounded quantification. Methods can not only modify the heap but also 
extend it by creating new objects. Thus a property that holds for all objects in 
the state before the call may not hold for all objects after the call. Therefore 
we sometimes have to restrict quantification to the objects that existed before 
the call. However, we only restrict quantification if the creational effects of the 
method indicate that an object of this class might be created by the method. 

Let n be the sequence that models the objects in the old heap. Let the effects 
of the method that is called be ip. Let ip = ( cs,fs ). Then we define the bounded 
variant 3z % : t(P) of an expression 3 z : t(P) as follows. 

3 z'ji : t(P ) = 3 z : t(P) for t £ {int(*), boolean!*)} 

3 . c (p ) = f 3z ; c (z G f iAP ) if V c ecs( c/ =< c ) 

M ‘ ^ ’ 1 3z : c(P) otherwise 

q-tf . r *(p) = \ 3z '■ C *( z C MAP) if V C6CS (C' =< c) 

M ^ 3z : c* (P) otherwise 

Note that quantification becomes bounded if the creational effects list a sub- 
class of the class that we consider. This is the right condition because the quan- 
tification domain of a class also contains the objects of subclasses. 



Restricting Assertions to the Old Heap. Another challenge is to find a 
counterpart of the substitution [y/x]. This substitution must do two things. 
It has to replace references to instance variables by the corresponding logical 
variables. And it must restrict quantification to the objects that existed in the 
old heap as argued above. We introduce the substitution J ^ for this purpose. 
Note that this substitution takes the effects ?/> of the method that is called into 
account. 

The most interesting case of this substitution is ( l.x ) J^,. It replaces l.x by 
its value in the old heap as described above. Let ip = ( cs,fs ). Assume that 
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origin (|Z|, x) = c (field x is defined in class c). Then we define this case as 
follows. 

a - > | _ J M*c)[f(Z.U)] if ( c > x ) G f s 

Jib otherwise 

We only substitute the instance variable if the write effects indicate that the 
method possibly changes its value. 

Another interesting case is (3 z : t(P))J^, which is defined as follows. 

{3z-.t{P))\^=3zi-.t{PU)) 

Thus the substitution J restricts quantification to the objects that existed in the 
state before the call. The quantification is not bounded if the creational effects of 
the method guarantee that no objects of a class will be created. All other cases 
of the substitution J ^ correspond to the usual notion of structural substitution. 

The Adaptation Rule. We can now state our rule of adaptation. We start 
with a simplified version of the rule for calls that have but one implementation. 
This is, for example, the case if a method is private, or if it is not overridden 
in some subclass. Let the statement u = eo-m(ei, . . . , e n ) involve a call to such 
a method. Let meth = m{u i, . . . , u n ){ v S return e } be the implementation of 
method m that is bound to the call. Let the effects ijj be sef(mei/i)(0). Then we 
have the following rule of adaptation (2) for such calls. 

{P'} v S {Q'[e/ result]} 

IocsAPJ^, AVzp (P'[e 0 , e/this, m] (,/,—> ~ > Q[result/u] 

{P} u := e 0 .m(ei, ,..,e n ) {Q} 

Observe that the rule has the same outline as the former rule except for the 
predicate Iocs. This predicates states that the local variables of the caller refer 
to objects in the old heap. It is the following formula: /\ ueU u € /i, where U is 
the set of all local variables that occur either in P, Q or e», for i G {0 . . . n}. 

The list z again contains all logical variables that occur free in P' or Q' 
(except the special-purpose logical variable result). The sequence v’ is a sequence 
of all local variables that occur free in Q' including this. We quantify over these 
local variables of the callee to prevent confusion with local variables of the caller 
in P or Q. The precondition of the method P' may only mention the formal 
parameters and this. All other local variables are out of scope in P' . 

The simultaneous substitution [eo, e/this, u] models the context switch. It 
replaces this by eo, and the formal parameters u = u\,...,u n by the actual 
parameters e = ei, . . . , e n . To prevent problems with field shadowing these sub- 
stitutions should preserve the types of the expressions by introducing casts if 
necessary (see [13] for further details). 

The special-purpose logical variable result denotes the result value. It is only 
allowed in postconditions of methods. The substitution [e/result] models a virtual 
assignment of the result value to result. Similarly, the substitution [result/u] 
models an assignment of this value to u. 
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Observe that the second premiss of the rule is the verification condition 
of a call with annotation {P} u = eo.m(ei, . . . ,e n ) {Q} in an object-oriented 
program where the corresponding implementation of method m has precondition 
P' and postcondition Q' . To be able to express the verification condition we 
extended the assertion language by allowing the function symbol f in assertions. 
However, this symbol will only occur in verification conditions. The proof outlines 
retain their desired abstraction level. 

The rule looks rather complex because it has to account for all possible 
contexts. In concrete contexts the resulting verification condition is often simpler. 
We give an example in Sect. 7. 

Next, we analyze reasoning about method invocations that are dynamically 
bound to an implementation. In such cases we have to consider all implementa- 
tions of method m that might possibly be bound to the call. Suppose again that 
we consider a call u := eo-m(ei, . . . , e n ). Recall that im pls( | eo I , m) denotes the 
set of classes that provide an implementation for this call. This set tells us how 
many implementations we must consider. 

A second consideration concerns the set of classes that inherit a particular 
implementation in some class c £ impls(|eo|], m). A class inherits the implemen- 
tation in class c if it is a subclass of class c and it is not a subclass of some class 
that overrides the implementation in class c. We denote the set of classes that 
override the implementation of method m in class c by overrides(c)(m). We have 
c' £ overrides(c)(m) if 

— d is a proper subclass of c that provides an implementation of method m, 
and 

— there does not exist another proper subclass c" of c such that c' is a proper 
subclass of c" , and c" also provides an implementation of method m. 

With this definition we can formulate in what circumstances the implementation 
of to in class c is bound to a method call eo.m(ei, . . . , e n ). That occurs when eo 
is an instance of a subclass of c and it is not an instance of a class that overrides 
this implementation. These conditions are expressed in the assertion language by 
the following formula: e 0 instanceof c A A c eo vemdes(c)(m) _, ( e 0 instanceof c'). 
We denote this formula by boundto(eo, c, m). 

Let impls(|eo[, to) = {ci, . . . , Cfc}. Let m(u \, . . . , u z n ){ Vi Si return e, } be 
the implementation of method m in class Cj, for i = 1 , ,k with effects ipi. We 
assume that the implementation of method m in class Ci has precondition P[ and 
postcondition Q\. Let Bi denote {P'} i’i Si {Q'[ej/ result]}. That is, Bi describes 
the specification of the implementation in class Cj. The verification condition V t 
for the implementation in class Ci is the implication 

locsAPJ^ Aboundto(eo, Cj, to) A 

^zp(P'[eo, e/this, u]\ 3u'(<2')) -» Q[result/u] . (Vj) 

Note that we have strengthened the antecedent with the clause that implies that 
the receiver is an object of a class that inherits the implementation of class c*. 
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class c { 
int x; 

requires u = U A this = O 
ensures O.x = U 

public void set(int it) { this.® := u; } 

requires u = U A this. a; = X 
ensures this.® = U A result = ( X = U) 
public boolean testAndSet (int u) { 
boolean b := (this.® = u); 

/*{ u = U Ab = (X = U) }*/ 
this ,set(u); 
return 6; } 



Fig. 2. An example proof outline 



The rule of adaptation for dynamically-bound method calls then simply 
checks if all specifications of implementations that might possibly be bound 
to the call can be adapted to the specification of the call. The rule results in one 
verification condition for each implementation. 

Vl , - - - , Vfc /gX 

{P} u = e 0 .m(ei, ...,e n ) {Q} 



7 An Example 

The rule as given above is certainly more complex that most other well-known 
Hoare rules. It can be conveniently used in proof outlines however if the veri- 
fication condition is computed automatically. We will give a small example of 
a program and the resulting verification condition in this section. The example 
mainly illustrates the elegant way in which the rule handles local variables. 

The example proof outline is listed in Fig. 2. The code defines a simple Java 
class with two methods. Each method is preceded by a precondition (requires 
clause) and a postcondition (ensures clause). The capital letters denote logical 
variables. 

It may seem strange that we also introduce a logical variable O in the precon- 
dition of the set method to refer to the old value of this in its postcondition. 
This is done because the verification condition puts an existential quantifier 
around occurrences of this in the postcondition of the method to prevent con- 
fusion with occurrences of this in the specification of the caller. A possible re- 
finement of the rule could make these steps superfluous by automatically adding 
the clause this = z to the precondition of the method and replacing this in 
the postcondition by z (where z is a fresh logical variable). 

The call this, set (u) is preceded by an intermediate assertion that is the 
precondition of the call. The postcondition of this call is obtained by substituting 
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result in the postcondition of the method by b. We assume that the methods are 
not overridden in subclasses. Therefore this call has the following verification 
condition. 

u — U A b = ( X = U) A this instanceof c 

A VO : c(V17 : int(u = U A this = O — * O.x = U)) 

— > this. a: = U A b = (X = £/) 

The effects of the set-method are (0, {(c, a;)}). That is, it creates no new 
objects and only modifies field x in class c. That explains why quantification 
in this verification condition is not bounded. The predicate Iocs is not needed 
to prove this particular verification condition and is therefore left out. It is not 
difficult to see that the above verification condition is valid if one chooses this 
for O. 

Observe that the clause b = (X = U) in the precondition of the call can be 
used to prove the same clause in the postcondition. The specification of the set 
method is unrelated to the local variables of the caller. 

8 Conclusions 

The main result of this paper is a (to the best of our knowledge) first rule of 
adaptation for the object-oriented paradigm. The rule not only enables us to 
adapt the values of logical variables but also results in an important separation 
of concerns for local variables in proof outlines for object-oriented programs. 
This improves the modularity of the specification. The rule uses a static ap- 
proximation of the effects of a method to further improve the modularity of the 
specification. We prove soundness of the adaptation rule in the full version [12] 
of this paper. 

The adaptation rule complements our earlier work on a (relatively) complete 
Hoare logic [13] for object-oriented programs. It is a well-known fact that the 
rule of adaptation can replace the substitution rule, the invariance rule, and the 
elimination rule without compromising completeness [11]. In the full version we 
show that this is also the case for the rule presented here. 

Proof outlines are not only a compact representation of correctness proofs 
but are also useful for documentation purposes. The rule of adaptation describes 
the verification condition that results from the specification of a call and the 
corresponding method. That is precisely what is needed in a proof outline logic. 
Thus the rule enables a shift from Hoare logics to proof outlines for 00. It is 
unclear if and how the rules that it replaces can be used in proof outlines. 

Future work includes an investigation of the sharpness [2, 9] of the proof rule. 
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Abstract. We describe a framework to generate modal abstract approx- 
imations from process algebraic specifications, written in the language 
/xCRL. We allow abstraction of state variables and action labels. More- 
over, we introduce a new format for process specifications called Modal 
Linear Process Equation (MLPE). Every transition step may lead to a set 
of abstract tates labelled with a set of abstract actions. We use MLPEs 
to characterize abstract interpretations of systems and to generate Modal 
Labelled Transition Systems, in which transitions may have two modal- 
ities may and must. We prove that the abstractions are sound for the 
full action-based /./-calculus. Finally, we apply the result to check some 
safety and liveness properties for the bounded retransmission protocol. 



1 Introduction 

The theory of abstract interpretation [4, 13] denotes a classical framework for 
program analysis. It extracts program approximations by eliminating uninter- 
esting information. Computations over concrete universes of data are performed 
over smaller abstract domains. The application of abstract interpretation to the 
verification of systems is suitable since it allows to formally transform possi- 
bly infinite instances of specifications into smaller and finite ones. By loosing 
some information we can compute a desirable view of the analysed system that 
preserves some interesting properties of the original. 

The achievement of this paper is to enhance existing process algebraic veri- 
fication tools (e.g. LOTOS, /iCR.L) with state-of-the-art abstract interpretation 
techniques that exist for state-based reactive systems. These techniques are based 
on lromomorphisms [3] (easier to use) or Galois Connections [16, 5, 12, 9] (more 
precise abstractions). The latter are sound for safety as well as liveness prop- 
erties. A tlrree-valued logic ensures that the theory can be used for proofs and 
refutations of temporal properties. We transpose this to a process algebra setting, 
allowing abstraction of states and action labels, and treating lromomorphisms 
and Galois Connections in a uniform way. A preliminary step was already taken 
in [7]; those authors show how process algebras can benefit from abstract inter- 
pretation in principle. To this end they work with a basic LOTOS language and 

* Partially supported by PROGRESS, the embedded systems research program of the 
Dutch organisation for Scientific Research NWO, the Dutch Ministry of Economic 
Affairs and the Technology Foundation STW, grant CES.5009. 
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a simple temporal logic; their abstractions preserve linear-time safety properties 
only. 

Semantically, our method is based on Modal Labelled Transition Systems [15]. 
MLTSs are mixed transition systems in which transitions are labelled with ac- 
tions and with two modalities: may and must. They are appropriate structures 
to define abstraction/refinement relations between processes. May transitions 
determine the actions that possibly occur in all refinements of the system while 
must transitions denote the ones that necessarily happen. On the one hand, the 
may part corresponds to an over-approximation that preserves safety properties 
of the concrete instance and on the other hand the must part under-approximates 
the model and reflects liveness properties. We define approximations and prove 
that they are sound for all properties in the full (action-based) /t-calculus [14], 
including negation. We had to extend the existing theory by allowing abstrac- 
tion and information ordering of action labels, which is already visible in the 
semantics of //-calculus formulas. This is treated in Section 2. 

This theory is applied to //CRL specifications [10], which (as in LOTOS) con- 
sist of an ADT part defining data operations, and a process specification part, 
specifying an event-based reactive system. Processes are defined using sequen- 
tial and parallel composition, non-deterministic choice and hiding. Furthermore, 
atomic actions, conditions and recursion are present, and may depend on data 
parameters. The /tCRL toolset [1,2] transforms specifications to linear process 
equations (LPE) . An LPE is a concise representation of all possible interleavings 
of a system in which parallel composition and hiding are eliminated. Several 
tools that manipulate LPEs have been developed; they do, for example, sym- 
bolic model checking, state space reduction, confluence analysis, etc... The //CRL 
language and tool set have been used in numerous verifications of communica- 
tion and security protocols and standards, distributed algorithms and industrial 
embedded systems. 

We implement abstract interpretation as a transformation of LPEs to MLPEs 
(modal LPEs). MLPEs capture the extra non-determinism arising from abstract 
interpretation. They allow a simple transition to lead to a set of states with 
a set of action labels. We show that the MLTS generated from an MLPE is a 
proper abstraction of the LTS generated from the original LPE. This implies 
soundness for /t-calculus properties. Section 4 is devoted to this part. The next 
figure shows the different possibilities to extract abstract approximations from 
a concrete specifications. 



(1) 

concrete spec (LPE) >- concrete system (LTS) 



( 4 ) 



( 3 ) 



(2) 



abstract spec (MLPE) 



( 5 ) 



abstract system (MLTS) 




Modal Abstractions in /rCRL 



411 



From a concrete system, encoded as an LPE, we can: 

— Generate the concrete transition system (1), from which we compute the 
abstraction (2). This solution is not very useful for verification because the 
generation of the concrete transition system may be impossible due to the 
size of the state space. 

— Generate directly the abstract Modal - LTS (3), by interpreting the concrete 
specification over the abstract domain. This solution avoids the generation 
of the concrete transition system. 

— First, generate a symbolic abstraction of the concrete system (4), and then 
extract the abstract transition system (5). 

Typically, standard abstract interpretation frameworks implement the second 
approach, however we believe that the third one is more modular. MLPEs act as 
intermediate representation that may be subjected to new transformations. Fur- 
thermore, MLPEs can be encoded as LPEs thus our method integrates perfectly 
with the existing transformation and state space generation tools of the /iCRL 
toolset. Also, the three valued model checking problem can be rephrased as the 
usual model checking problem, along the lines of [9]. This enables the reuse of 
the model checkers in the CADP toolset [8] . The latter two transformations are 
not detailed in the current paper. 

The main part of the theory mentioned above has been defined and proved 
correct in an elegant way using the computer assisted theorem prover PVS [18]. 
The use of the theorem prover gives extra confidence about the correctness of the 
theory. Furthermore, the definitions and proofs can be reused to easily extend 
the theory, to prove other transformations, or to apply the same techniques to 
another specification language. Also, this prover could be used to prove the safety 
conditions generated for user-specified abstractions. 

To improve usability, we have predefined a few standard abstractions. Of 
course, the user can define specific abstractions, which in general lead to the 
generation of safety conditions. Finally, thanks to the uniform treatment, the 
tool can automatically lift a (predefined or user specified) homomorphism to a 
Galois Connection, thus combining ease with precision. 

As running example we use a simple system in which two processes com- 
municate by sending natural numbers through a channel described as a FIFO 
buffer of size N, see the figure below. The system has two sources of infinity: 
the size of the buffer and the value of the data, which should be abstracted 
if we want to apply model checking techniques to its verification. Finally, we 
demonstrate the method by checking some safety and liveness properties of the 
bounded retransmission protocol in Section 5. 
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2 Transition Systems 

Part of the results included in this section are well known in the field of ab- 
stract interpretation. We adapt classical frameworks for generating safe abstract 
approximations, by doing a non-trivial extension of them in order to allow the 
explicit abstraction of action labels which will permit to manipulate infinitely 
branching systems. First, we start by defining some general concepts and then 
we continue by introducing the two abstraction techniques. 

The semantics of a system can be defined by a Labelled Transition System. We 
assume a non-empty set S of states, together with a non-empty set of transition 
labels A: 

Definition 1 A transition is a triple s A s' with a £ A and s,s' £ S. We define 
a Labelled Transition System (LTS) as tuple (S,A,—>, so) in which S and A are 
defined as above and — > is a possibly infinite set of transitions and s o in S is the 
initial state. 

To model abstractions we are going to use a different structure that allows 
to represent approximations of the concrete system in a more suitable way. As 
introduced before, in Modal Labelled Transition Systems transitions have two 
modalities may and must which denote the possible and necessary steps in the 
refinements. This concept was introduced by Larsen and Thomsen [15]. Let us 
see the definition: 

Definition 2 A Modal Labelled Transition System (MLTS) or may/must la- 
belled transition system ('may/must -LTS) is a tuple (S, A, — — >□, so) where 
S, A and s o are as in the previous definition and — >o,~ are possibly infinite 
sets of (may or must) transitions of the form s s' with s, s' £ S, a £ A 
and x £ {<>,□}. We require that every must -transition is a may -transition 

r-? D c-?o;. 

MLTSs are suitable structures for stepwise refinements and abstractions. A 
refinement step of a system is done by preserving or extending the existing must- 
transitions and by preserving or removing the may-transitions. Abstraction is 
done the other way around. To every LTS corresponds a trivially equivalent 
MLTS constructed by labelling all transitions with both modalities; we will call 
it the corresponding concrete MLTS. 

Having a set of states S and a set of action labels A with their corresponding 
abstract sets, denoted by S and A, we define a homomorphism H as a pair of 
total and surjective functions ( hs,hA ), where hs is a mapping from states to 
abstract states, i.e., hs : S — > S, and Iia maps action labels to abstract action 
labels, i.e., h-A : A — > A. The abstract state s corresponds to all the states s for 
which hs(s) = s, and the abstract action label a corresponds to all the actions 
a for which Ha ( a ) = a. 

Definition 3 Given a concrete MLTS P (S, A, — »<>, — >□, so) and a mapping 
H , we say that P defined by (S, A, — ><>, — >□, So) is the minimal may/must#- 
abstraction (denoted by P = minni^P)) if and only if hs(so) = so and the 
following conditions hold: 
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— s' — >o r •<=>■ 3 s, r, a. /ig(s) = 's A hs(r) = r A /i^(a) = a A s r 

— s' r ■<==>■ V s.hs{s ) = s. (3 r, a. /ig(r) = r A /ia(«) = a A s A D r) 



This definition gives the most accurate abstraction of a concrete system by using 
a homomorphism, in other words the one that preserves most information of the 
original system. The figure below shows, on the left side, the concrete MLTS 
corresponding to the buffer model 1 . In the middle we see the minimal abstraction 
of the system by only abstracting states with hs defined as follows: it maps the 
initial state to the abstract state e, which means empty , the states in which 
there are N entries in the buffer to /, which represents full, and the rest of the 
states to m , which means something in the middle ; we can see that the resulting 
abstract system is infinitely branching, therefore in order to be able to do model 
checking to the system we need also to abstract the action labels. We define Iia 
as follows: it maps all the write actions to w and all the read actions to r. On the 
right side, we see the result of applying both abstractions. In the final system, 
we have removed all the information about the values that are in the buffer and 
the transferred data, only preserving the information about whether the buffer 
is empty, full or none of them. This abstraction allows to have a small finite 
model which keeps some information about the original. The example clearly 
illustrates the importance of the abstraction of action labels. 





Instead of using mappings between concrete and abstract domains we can define 
relations. The other classical approach we present is based on Galois Connections 
between domains, and it was introduced in the late seventies by Cousot and 
Cousot [4], see also [5] for a good introduction. Two functions a and 7 over two 
partially ordered sets (P, C) and (Q, 4 .) such that a : P — * Q and 7 : Q — > P 
form a Galois Connection if and only if the following conditions hold: 

1 . a and 7 are total and monotonic. 

2. \/p : P,p C 70 a(p). 

3. Mq : Q, a 07 (g) ^ q. 

1 For clarity we use dashed lines to represent may transitions and normal lines to 
represent must transitions. Note that when there is a must transition we do not 
include the corresponding may one. 
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a is the lower adjoint and 7 is the upper adjoint of the Galois Connection, and 
they uniquely determine each other. Galois Connections enjoy suitable properties 
to perform abstractions. Let V(S) and V(A) be partially ordered sets ordered by 
the set inclusion operator and the abstract S and A both being posets equipped 
with some order =<;. The order gives a relation of the precision of the information 
contained in the elements of the domain. We define a pair G of Galois Connec- 
tions: G = ((as, 7s), (o:a,7a))- a is usually called the abstraction function and 
7 the concretization function. As in the previous case we define the minimal 
abstraction, as follows: 

Definition 4 Given two systems P and P defined as in definition 3 and a pair 
of Galois Connections G, P is the minimal may/mustc-abstraction ( denoted by 
P = mino(P) ) if and only if So £ 75 (So) an d the following conditions hold: 

- sA 0 r 3 s G 7s (s), r € 7s (f), a £ 7 a(o).s r 

- s A 0 r 4=> Vs e 7s(s). (3 r £ 73(f), a £ 7 a (a), s A D r) 

The following figure presents a part of the minimal abstraction of the buffer 
system 2 . On the left side we can see the two abstract lattices, and on the right 
side we see the transitions corresponding to the abstract write and read actions. 
The abstract lattices are: {_L, e, m, /, nE, nF, T} and {_L,w;, f, T}, the Galois 
Connection is trivially defined following the previous example and considering 
that nE represents the states in which the buffer is not empty and nF in which 
it is not full. 

/ T \ WRITE w READ V 



nF nE 




Due to the order over the abstract states and actions, the minimal system defined 
by the above presented definition is saturated of may and must transitions, i.e. 
there are transitions that do not add any extra information. We can easily see in 
the previous figure that the must part is saturated for example, the transition 

e nE does not add any information because we have e m which is more 
precise. We can restrict our definition by requiring that the abstract transitions 

2 For readability, we separate write transitions: and read transitions A and we do 

not include transitions to and from T, or labelled with it. 
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are performed only between the most precise descriptions of the concrete tran- 
sitions, as done in [5] 3 . In the previous figure, this would remove: e -^<>,n nF, 
e — ->o,d nE, to nF, m —>o nE , / -^<>,n nF, f nE, nF <> nF and 

nE ^>0 nE. We call the system in which all redundant transitions have been 
eliminated restricted and it is denoted by P{. 

We formalize now the approximation relation between MLTSs: 

Definition 5 Given two MLTSs P (S,A,—*o,—*n,so) and Q (S,A,- s ‘<>,— i -n 
, so) built over the same sets of states (S,=4s) an d actions (A, = 4 a); Q is an 
abstraction of P, denoted by P Q, if the following conditions hold: 

- V s,a, r, s', s -^>0 r A s^s' => 3 a', r' . s' o r' A r =^g r' A a = 4 a a' 

— V s' , a' , r' , s. s' r' A s =^s s' ==> 3 a, r. s Aq r A r =^s r' A a =4 a a' 

P Q means that Q is more abstract than P and it preserves all the infor- 
mation of the may-transitions of P and at least all must transitions present in 
Q are reflected in P. The may part of Q is an over-approximation of P and the 
must part is an under-approximation. The refinement relation is the dual of the 
abstraction. Note that for the homomorphism approach there is no order defined 
between states or actions so we substitute =$ by =. 

3 Logical Characterization 

To express properties about systems we are going to adapt the highly expressive 
temporal logic (action-based) /./-calculus [14] which is defined by the following 
syntax, where a is an action in A: 

tp ::= T | F \ ->ip \ ipi A <p 2 | <fii V <p 2 \ [a]y> | {a)(p \ Y \ pY.p \ 1 sY.ip 

Formulas are assumed to be monotonic. Following [12], a given formula is inter- 
preted dually over an MLTS, i.e. there will be two sets of states that satisfy it. A 
set of states that necessarily satisfy the formula and a set of states that possibly 
satisfy it. Thus, the semantics of the formulas is given by [y>] € 2 s x 2 s and the 
projections |[^>]” ec and I^] pos give the first and the second component, respec- 
tively. We show below the simultaneous recursive definitions of the evaluation of 
a state formula. In the state formulas, the propositional context p : Y — » 2 s x 2 s 
assigns state sets to propositional variables, and the 0 operator denotes con- 
text overriding. Note that the precision order between action labels plays an 
important role in the definition of the semantics of the modalities. 



The main difference with Dams’ approach is that we preserve the condition — ?nC— ?<>■ 



3 
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m P =(0j) 

PIp =(S,S) 

1^} P = (S^plp 08 , <S"\pJ p ec ) (Note the switch of pos and nec) 

ipi a ^ip = (Piir n Mr- w s n p 2 ir) 
pi v Hp = (Piir u p2ir - piir u i^id 

[[aplp =({5|Vr,a'.a^a'As\r=4r€ PJ" 60 }, 

{s | Vr, a', a' =4 a A s r4r€ Plp OS }} 

|(a)<p]p = ({« | 3r,o'.a'^«As — >□ r A r G p]™ ec }, 

{s | 3r,a'.a^a'As -Po r A r £ p]p OS }) 

PIp = P(P 

IPvIp = (fl{^ C 5 | 4£“(S') C 5'}, DI5' C 5 | <j*«”(S') C S 1 }) 

\vY.<p Ip = 0J{^ C S' | S" C ^ ec (S')},U{5'' C S | S' C **“(S')}) 

where : 2 s -> 2 s with x £ {nec, pos}, $*{S') = p]f p0[5 /Y ]) 



We say that a state s necessarily satisfies a formula <p, denoted by s j= nec p, iff 
s £ p] nec and dually s possibly satisfies a formula p, denoted by s |= pos p, iff 
s £ p] pos . We remark that from the semantics of the negation follows: 

— s necessarily satisfies —>p iff s not possibly satisfies p. 

— s possibly satisfies —>p iff s not necessarily satisfies p. 

It is not difficult to see that if s necessarily satisfies a formula p then also s 
possibly satisfies p. This follows from the fact that every must - transition is also 
a may-transition. Without this condition we would be able to prove s |= nec p and 
s |= nec -i p for some p which will lead to an inconsistent logic. In fact, it cannot be 
proved for any p s |= raec p and also s |=" ec -<p, i.e. the necessarily interpretation 
is consistent and it is always possible to prove s \ = pos p or s |= pos ->p which 
means that the possibly interpretation is complete. The semantics gives a three 
valued logic: 

— s necessarily satisfies p. 

— s possibly satisfies p but not necessarily satisfies p. 

— s not possibly satisfies p. 

Since the abstraction of a system preserves some information of the original one, 
the idea is to prove properties on the abstract and then to infer the result for 
the original. Since action labels occur in ^-calculus formulas, formulas over A 
are distinct from formulas over A. Therefore, we need to define the meaning of 
the satisfaction relation of an abstract formula on a concrete state: p]j where 
£ is either Iia or a a depending on whether we use a homomorphism or a Galois 
Connection. p]j gives the set of concrete states that ( necessarily or possibly) 
satisfy an abstract formula. An extract of the necessarily semantics is given 
below, note that for the rest of the cases (T, F, A, V and fixpoints) the definition 
does not change, and the possibly semantics are dual: 
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\[a}(pfl ec = {s | Vr, a.a ^({«})As\ r => r £ | [^]j ec } 

[(a)^]j ec = {s | 3r,a.(({a}) 4 a As A D r A r G |^]j ec } 

A concrete state s necessarily satisfies the abstract formula (p, denoted by s \=™ ec 
ip, iff s € |^]j ec - And dually, s |=^ os ip, iff s € Now we can give the 

property preservation result: 

Theorem 6 Let P be the MLTS (S, A, — »<>, — >□, so), X be either a homomor- 
phism H = ( hs , h a) between (S, A) and (S, A) [ in which case £ stands for h] or 
a Galois Connection G= ((as, 7s), («A) 1a)) between (V(S),V(A)) and (S,A) 
[ in which case ( stands for a] and let P| (over S and A) be the minimal (re- 
stricted) abstraction of P. And finally let p be a formula over A, then for all 
p £ S and p £ S such that £({p}) p: 

- p |=«ec Q ^ p ^ nec ~ 

- p ^pos ~ 

The proof follows from the fact that every may trace of P is mimicked on P by 
some related states and, on the other hand, every must trace of P is present in 
P. We refer to the technical report [19] for the proof. 

The theorem states that we can infer the satisfaction of a formula on a 
concrete system if it is necessarily satisfied on the abstract. Furthermore, if 
the formula is not possibly satisfied on the abstract it will not hold on the 
concrete either, so it can be refuted. For example, the two presented abstractions 
(by homomorphism and by Galois Connection) prove: “It is possible to write 
something if the buffer is empty ” expressed as e |= nec ( w)T , which means that 
in the concrete system sq either satisfies ( w(0))T or (w(l))T or (w(2))T or 
. . . Furthermore, we can prove on the abstract / Y= pos (w)T which means that 
in the concrete, all the corresponding concrete states satisfy neither (w(0))T nor 
(w(l))T nor (w(2 ))T nor . . . 

In general, abstractions produced by using Galois Connections preserve more 
information than the ones generated by homomorphisms, however the state space 
reduction is stronger in the latter case. For example, the abstraction with the 
Galois Connection can prove absence of deadlock since there is a must transition 
from every state that may be reached, however the abstraction done by the 
homomorphism is not able to prove the property for there is no must transition 
from the state middle so we cannot infer the existence of some transition from 
the related states in the concrete system. 

Abstract approximations also preserve properties, this idea is stated in the 
following lemma: 

Lemma 7 Given two MLTSs P and Q, over the same sets of states and labels 
S and A, with P Q then for all p and q in S such that p 4 q and for all 
formula p then: 
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-q\= Q c v=>ph n P ec v 

This result is useful because, by performing symbolic abstractions (see next 
section) we generate approximations of the minimal abstraction, so the lemma 
states that we can still infer the satisfaction/refutation of the properties from 
the approximation to the original. 



4 Process Abstraction 

/zCRL is a combination of process algebra and abstract data types. Data is 
represented by an algebraic specification fl = (17, E), in which E denotes a many- 
sortecl signature (S, F), where S is the set of sorts and F the set of functions, and 
E a set of E- equations, see [10]. All specifications must include the boolean data 
type with the constants true and false (T and F). From process algebra /xCRL 
inherits the following operators: p.q (perform p and then perform q); p + q 
(perform arbitrarily either p or q); Yld-D p(d) (perform p{d) with an arbitrarily 
chosen d of sort D); p < b > q (if b is true, perform p, otherwise perform q); p 
I I q (run processes p and q in parallel). S stands for deadlock. Atomic actions 
may have data parameters. Every /zCRL system can be transformed to a special 
format, called Linear Process Equation or Operator. An LPE (see definition 
below) is a single ^(CRL process which represents the complete system and from 
which communication and parallel composition operators have been eliminated. 

X(d : D) = EE ai{fi[d,ei]).X{gi[d,ei]) < Ci[d,ei\ > S (1) 

ei’.Ei 

In the definition, d denotes a vector of parameters d of type D that represents 
the state of the system at every moment. We use the keyword init to declare 
the initial vector of values of d. The process is composed by a finite number I of 
summands, every summand i has a list of local variables e,, of possibly infinite 
domains, and it is of the following form: a condition cy [d, a ] , if the evaluation 
of the condition is true the process executes the action a, with the parameter 
fi[d,ei) and will move to a new state gi[d,ei], which is a vector of terms of 
type D. fi[d,ei],gi[d,ei\ and c*[d, e*] are terms built recursively over variables 
x £ [d, 6i], applications of function over terms t = f(t') and vectors of terms. To 
every LPE specification corresponds a labelled transition system. The semantics 
of the system described by an LPE is given by the following rules: 



so — >nit / p f 

— s — > s' iff there exist i £ I and e : Ei such that c,[s,e] = T, aj(/)[s,e]) = a 
and gi[s, e] = s' 

Terms are interpreted over the universe of values T>. The following /iCRL speci- 
fication corresponds to the LPE of the example, in which the buffer is modeled 
by a list: 
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X(l : List ) = W ( d).X(cons(d , l)) < length(l ) < TV > 5+ 

d-.D 

R(head(l)).X(tail(l)) < 0 < length(l) O <5 



4.1 Abstract Interpretation of pCRL: Data Part 

In order to abstract pCRL specifications we may define the relations between 
concrete and abstract values by means of a mapping H : V — •> V or a Galois 
Connection ( a : V(V) — > V, 7 : V — > V(V)). 

To abstract data terms, first a mapping ~ on (lists of) data sorts must be 
provided. D represents the sort to which D is abstracted. We require that 
Bool = Bool. Next, for each function symbol /, its abstract counterpart / 
must be provided. In particular, if / : D — > E then / : V(D) — > V(E). These 
ingredients allow to extend ~ to data terms, by replacing all symbols by their 
abstract counterpart. In particular, a data term t : D with variables x : E is 
abstracted to a data term t : V{D) with variables x : V(E). 

We now explain why we lifted all symbols to sets of abstract sorts. For ex- 
ample, in our buffer specification we may have a function S which computes 
the successor of a natural number. The abstract version of S may be defined as 
follows: 

— For the homomorphism case: S (empty) = middle, S (middle) = middle or 
S (middle) = fidl. It will be undefined for full. 

— For the Galois Connection approach: S(empty) = middle, S(middle) = 
nonEmpty , S(nonFull) = nonEmpty, S(nonEmpty) = nonEmpty, S(full) 
= T, S(±) = _L and S( T) = T. 

Abstract interpretation of functions may add non-determinism to the system, 
for example S (middle) in the homomorphism case may return different values 
( middle and full). Furthermore, not all the sorts of a specification need to be 
abstracted, for example, a predicate empty 1 applied to empty will return true, 
however, applied to nonFull it can be either true or false. To deal with these 
two considerations, we have lifted abstract functions to return sets of values. So 
for the homomorphism case, S ({middle}) = {middle, full}. For the Galois case, 
S({empty}) = {nonEmpty} and empty! (nonFull) = {T,F}. 

Not all possible abstract interpretations are correct; in order to generate 
safe abstractions the data terms involved in the specification and their abstract 
versions have to satisfy a formal requirement, usually called safety condition. The 
condition for the homomorphism function and Galois connections are expressed 
as follows (note that in the second case t is applied pointwisely to sets). 

— Homomorphism: for all d in D. H(t[d]) £ t [ {H(d)} ] 

— Galois connection: for all d in D.t[d] > a(t['y(d)]) 
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4.2 Abstract Interpretation of pCRL: Process Part 

We will now present a new format, the Modal Linear Process Equation (MLPE), 
and the abstraction mapping from LPEs to MLPEs. An MLPE has the following 
form: 



X(d:Vm = J2H a i (Fi[d,ei]).X(G i [d,e i ]) < Ci[d,ei] > <5 (2) 

ei'.Ei 

The definition is similar to the one of Linear Process Equation, the difference 
is that the state is represented by a list of powersets of abstract values and for 
every i: Ci returns a non-empty set of booleans, Gi a non-empty set of states 
and F t also a non-empty set of action parameters. Actions are parameterized 
with sets of values, as well. From an MLPE we can generate a Modal Labelled 
Transition System following these semantic rules: 

So = init TO * pe 

— S S' iff there exist i € I and e € £) such that F ^ Ci[S, e], A = a(Fi[S, e]) 
and S' = Gi [S', e] 

— S — >o S' iff there exist i € I and e € Ei such that T £ Ci[S, e], A = a(Fi[S, e]) 
and S' = Gi[S, e] 

To compute an abstract interpretation of a linear process, we define the 
operator “ " ” : LPE — > M LPE that pushes the abstraction through the process 
operators till the data part: 

p = X(t) then p = X(t) where X is a process name p = po-Pi then p = po-Pi 

p = a{t) then p = a(t) where a is an action label p = 5 then p = 5 

p = po + ... +Pn then p = po + ... + p„ p = J2 e:E P tlien P = J^z-.eP 

p — pi <it c > p r then p = pi <1 t c > p r 



MLPEs allow to capture in a uniform way both approaches: Galois Connection 
and Homomorphism as well as the combination of both consisting in the lifting of 
a mapping to a Galois Connection. The lifting is done by considering the abstract 
domain as a lattice over the powerset of the abstract values ordered by subset in- 
clusion and a (A) will be defined as {H(x) \ x £ X} and 7 (X) as {x \ H(x) € X}. 
In the example, the abstract values nonEmpty and nonFull will be captured 
by {middle, full} and {empty , middle} respectively. The successor of nonFull 
will be the union of the successor of empty and middle : {middle, f ull}. In this 
example, the lifting of the homomorphism saves the extra effort of defining ab- 
stract functions. In case we use a plain homomorphism (without lifting it to a 
Galois Connection), we restrict the semantics of the MLPE by letting So, S, A 
and S' be only singleton sets. The MLPE below models the buffer example: 



X{1 : V(List)) = w{d).X{cons{d, l)) <3length(l) < N > <5+ 

d-.D 

r(head(l)) .X (tail(l)) <1 0 < length(l) > 6 
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Just considering that all functions are pointwisely extended in order to deal 
with sets of values, the above MLPE can be used equally for any kind of relation 
between the data domains: homomorphisms, arbitrary Galois Connections and 
lifted homomorphisms. The following theorem asserts that the abstract interpre- 
tation of a linear process produces an abstract approximation of the (restricted) 
minimal abstraction of the original. 

Theorem 8 Let lpe be Linear Process Equation (as defined in (1)), mlpe a 
Modal Linear Process Equation (as defined in (2)) and X an abstraction relation 
between their data domains (where X is either a homomorphism or a Galois 
Connection) . Then if: 

1. mlpe is the abstract interpretation of lpe (mlpe = lpe), 

2. mlts is the concrete MLTS generated from lpe 

3. mlts). is the (restricted) minimal w.r.t X of mlts 

4- All pairs (f,F), ( g,G ) and (c, C) satisfy the safety condition. 

— Then, the MLTS (mlts) generated from mlpe is an abstraction o/mltsj., i.e, 
(mlts). mlts) 

lpe >- mlts 



lpe ► mlts □-<; mlts). 

The proof is done by checking that every may transition generated by the ab- 
stract Modal Linear Process Equation has at least one more precise counterpart 
in the (restricted) minimal abstraction of the concrete system (and the other way 
around for the must transitions). By Theorem 6 and Lemma 7, we can prove 
(refute) properties for lpe by considering mlpe directly. 



5 The Bounded Retransmission Protocol 

The BRP is a simplified variant of a Philips’ telecommunication protocol that 
allows to transfer large files across a lossy channel. Files are divided in packets 
and are transmitted by a sender through the channel. The receiver acknowledges 
every delivered data packet. Both data and confirmation messages, may be lost. 
The sender will attempt to retransmit each packet a limited number of times. 

The protocol has a number of parameters, such as the length of the lists, 
the maximum number of retransmissions and the contents of the data, that 
cause the state space of the system to be infinite and limit the application of 
automatic verification techniques such as model checking. Following the ideas 
presented along the paper, we abstract the specification by eliminating some un- 
interesting information. We base our solution on the /xCRL model presented in 
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the paper [11], in which Groote and van de Pol proved using algebraic methods 
that the model is branching bisimilar to the desired external behavior also spec- 
ified in /iCRL. This proof requires a strong and creative human interaction in 
order to be accomplished. However by computing an abstraction of the original 
specification we can automatically model check some properties. 

The system is composed by a sender that gets a file which consists of a list 
of elements. It delivers the file frame by frame through a channel. The receiver 
sends an acknowledgment for each frame, when it receives a packet it delivers 
it to the external receiver client attaching a positive indication If s t, hnc or I 0 k- 
The sender, after each frame, waits for the acknowledgments, if the confirma- 
tion message does not arrive, it retransmits the packet. If the transmission was 
successful, i.e. all the acknowledgments have arrived, then the sender informs 
the sending client with a positive indication. When the maximum number of 
retransmissions is exceeded, the transmission is canceled and I no k is sent to the 
exterior by both participants. If the confirmation of the last frame is lost the 
sender cannot know whether the receiver has received the complete list, therefore 
it sends “I don’t know” to the sending client, Idk- 

We are interested in proving that the external indications delivered by the 
sender and the receiver are “consistent”. For that purpose, we chose an abstrac- 
tion that abstracts away the data stored in the file and maps the list to three 
critical values: abs-empty, abs-one, absjmore. The first one denotes the empty 
list, abs_one when it has only one element, and abs-more when it has more than 
one. The maximum number of retransmissions is removed (abstracted to a single 
abstract value abs-N) which makes the sender to non-deterministically choose 
between resending a lost packet or giving up the transmission. 

The next table presents the abstract specification of the data and the ab- 
straction mappings. The concrete specification of the list and the sort Nat are 
standard. The function indl indicates by a bit whether a list is at its end (it is 
empty or has only one element) or not. 



sort abs-D , abs-Nat , abs-List 
func abs-D > abs-D 
abs-N » abs-Nat 
abs -empty > abs-List 
abs-one > abs-List 
absjmore > abs-List 
succ : abs-Nat —* V (abs-N at) 

It : abs-Nat x abs-Nat — > V(Bool) 
head : abs-List — > V (abs-D) 
tail : abs-List — * V (abs-List) 
last : abs-List — > 'P(Bool) 
indl : abs_List —> V(Bit) 
var l » abs_List 
rh , n : abs_Nat 
rew succ(rh) = {abs_N} 
lt(rh , h) = {t, f } 
head(l ) = {abs_D} 
tail (abs .empty) = {abs^empty} 
tail(abs-one) = {abs-empty} 



tail (abs -more) = 

{ absjmore , abs-one} 
last (abs -empty) = {t} 
last(abs-one) = {t} 
last (abs -more) = {f } 
indl (abs -empty) = {ei} 
indl (abs-one) = {ei} 
indl (abs -more) = {eo} 
func H : List — > abs-List 
H : D — > abs-D 
H : Nat —> abs-Nat 
var l : List 
d,d' : D 
m : Nat 

rew H (empty) = abs-empty 

H(add(d , empty)) = abs-one 
H(add(d , add(d ' , l))) = absjmore 
H(d) = abs-D 
H(m) = abs-N 
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This abstraction allows to reason about the execution of the final part of the 
protocol without knowing the exact content of data files or the number of retrials. 
For example the following safety property: “after a positive notification by the 
receiver, the sender cannot send a negative one” is necessarily satisfied by the 
abstract system. We express the property in the Regular Alternation- free //- 
calculus, which is a fragment of the modal /./-calculus extended with regular 
expressions, as follows 4 : 

[T* .'Rmayi.*, {/«*})’■(-> ’S.* ’)* ■' ’S m „» {{luck } ) ’] F 

The following liveness property expresses that: “After a negative notification 
by the receiver, there exists a path which leads to a negative or don’t know 
notification by the sender”. 

[T* .’R may{-*, {Aiofc})’] (’• *must ’* • {’Smust {{Inok }) ’ V ’S must({Idk})’)} T 

The next property is stronger than the previous, instead of only requesting that 
there exists a path it states that the expected sender notification is inevitably 
achieved: 

[T* .’R m a;/(.*, {Inok})'] gX((’- T A [~i( ’S must ({Inok})’ V ’Smust {{Idk }) ’)] X) 

These three properties are necessarily satisfied in the abstract system, therefore 
we can infer its satisfaction in the original one. However, the following property 
which states that ’’after a positive notification by the receiver there exists a 
path which leads to a positive or don’t know notification by the sender” is not 
satisfied in the abstract system. The reason is that we have abstracted away the 
maximum number of retransmissions, therefore if all the acknowledgments are 
lost the sender can retransmit the frames forever: 

[ T * . Rmay (•*, {Cfc}) ] ( - *must * - ( Smust ({ lofc }) V S )} T 

Other papers have verified some properties of the protocol using abstract in- 
terpretation, we refer among others to [17, ?]. The approach of Manna et al. is 
based on automatic predicate abstractions and is limited to the proof of invari- 
ants. However Dams and Gertlr propose a number of creative abstractions in 
order to prove the satisfaction of some safety properties about the sequentiality 
on the delivering of the frames. 



6 Conclusion 

In order to apply the abstract interpretation framework for reactive systems [5, 
12] to ^/CRL processes, we extended it with the explicit abstraction of action 
labels. This required non-trivial changes in most definitions. A /iCRL specifi- 
cation in LPE-form can be abstracted to a modal LPE; the state space of this 
MLPE corresponds to a reduced MLTS, approximating the original LTS. This 

4 We have used the CADP model checker to prove the properties we describe, therefore 
we present the formulas with the CADP syntax. The reader not familiar with the 
logic can safely skip them. 
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approximation can be used to verify and refute safety as well as liveness formulas 
for the original system. 

The resulting approach incorporates the homomorphism approach (which 
is easier to understand and use) and the Galois Connection approach (which 
preserves more properties, especially liveness properties). A user-defined homo- 
morphism can also be lifted to a Galois Connection automatically, combining 
ease with precision. 

We already have a working prototype implementation, which will be de- 
scribed in a separate paper. It is based on a projection of MLPEs to LPEs, in 
order to reuse existing state space generation tools. We will apply the techniques 
from [12] in order to translate the three- valued model checking problem to regular 
model checking, in order to also reuse a model checker for the modal /^-calculus, 
e.g. CADP [8]. Another interesting question, optimality of abstractions, can in 
principle be addressed along the lines of [5]. 

Our theory allows the collection of standard data abstractions with accom- 
panying safety criteria proofs. Such abstraction libraries can be freely used in 
various protocols, without additional proof obligations. This will enhance auto- 
matic verification of protocols in specialized domains. 

Model checking becomes more and more crucial for the correctness of soft- 
ware, but in practice additional techniques, such as abstraction, are needed. This 
may affect the correctness and modularity of the resulting verification methodol- 
ogy and tools. We support modularity by implementing abstraction as an LPE to 
LPE transformation, which can be composed freely by other existing transforma- 
tions [1] . We feel that it is important to provide a rigorous basis for verification 
technology, so we have checked the main part of the results in this paper in the 
theorem prover PVS. 
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Abstract. In this paper, we give an operational and denotational se- 
mantics for a 3APL met a- language, with which various 3APL inter- 
preters can be programmed. We moreover prove equivalence of these two 
semantics. Furthermore, we relate this 3APL meta-language to object- 
level 3APL by providing a specific interpreter, the semantics of which 
will prove to be equivalent to object-level 3APL. 



1 Introduction 

An agent is commonly seen as an encapsulated computer system that is situated 
in some environment and that is capable of flexible, autonomous action in that 
environment in order to meet its design objectives [19]. Autonomy means that 
an agent encapsulates its state and makes decisions about what to do based on 
this state, without the direct intervention of humans or others. Agents are situ- 
ated in some environment which can change during the execution of the agent. 
This requires flexible problem solving behaviour, i.e. the agent should be able to 
respond adequately to changes in its environment. Programming flexible com- 
puting entities is not a trivial task. Consider for example a standard procedural 
language. The assumption in these languages is, that the environment does not 
change while some procedure is executing. If problems do occur during the ex- 
ecution of a procedure, the program might throw an exception and terminate 
(see also [20]). This works well for many applications, but we need something 
more if change is the norm and not the exception. 

A philosophical view that is well recognized in the AI literature is, that ra- 
tional behaviour can be explained in terms of the concepts of beliefs , goals and 
plans 1 [1, 13,2]. This view has been taken up within the AI community in the 
sense that it might be possible to program flexible, autonomous agents using 
these concepts. The idea is, that an agent tries to fulfill its goals by selecting 
appropriate plans, depending on its beliefs about the world. Beliefs should thus 
represent the world or environment of the agent; the goals represent the state of 
the world the agent wants to realize and plans are the means to achieve these 
goals. When programming in terms of these concepts, beliefs can be compared 

1 In the literature, also the concepts of desires and intentions are often used, besides 
or instead of goals and plans, respectively. This is however not important for the 
current discussion. 
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to the program state, plans can be compared to statements, i.e. plans constitute 
the procedural part of the agent, and goals can be viewed as the (desired) post- 
conditions of executing the statement or plan. Through executing a plan, the 
world and therefore the beliefs reflecting the world will change and this execution 
should have the desired result, i.e. achievement of goals. 

This view has been adopted by the designers of the agent programming lan- 
guage 3APL 2 [8]. The dynamic parts of a 3APL agent thus consist of a set of 
beliefs, a plan 3 and a set of goals 4 . A plan can consist of sequences of so-called 
basic actions and abstract plans. Basic actions change the beliefs 5 if executed 
and abstract plans can be compared to procedure names. To provide for the 
possibility of programming flexible behaviour, so-called plan revision rules were 
added to the language. These rules can be compared to procedures in the sense 
that they have a head (the procedure name) and a body (a plan or statement). 
The operational meaning of plan revision rules is similar to that of procedures: 
if the procedure name or head is encountered in a statement or plan, this name 
or head is replaced by the body of the procedure or rule, respectively (see [4] 
for the operational semantics of procedure calls) . The difference however is, that 
the head in a plan revision rule can be any plan (or statement) and not just 
a procedure name. In procedural languages it is furthermore usually assumed 
that procedure names are distinct. In 3APL however, it is possible that multiple 
rules are applicable at the same time. This provides for very general and flexible 
plan revision capabilities, which is a distinguishing feature of 3APL compared 
to other agent programming languages [12, 14, 6]. 

As argued, we consider these general plan revision capabilities to be an es- 
sential part of agentlroocl. The introduction of these capabilities now gives rise 
to interesting issues concerning the semantics of plan execution, the exploration 
of which is the topic of this paper. 

Semantics of plan execution can be considered on two levels. On the one 
hand, the semantics of object-level 3APL can be studied as a function yielding 
the result of executing a plan on an initial belief base, where the plan can be 
revised through plan revision rules during execution. An interesting question is, 
whether a denotational semantic function can be defined that is compositional 
in its plan argument. 

On the other hand, the semantics of a 3APL interpreter language or meta- 
language can be studied, where a plan and a belief base are considered the data 
on which the interpreter or meta-program operates. This meta-language is the 
main focus of this paper. To be more specific, we define a meta-language and 
provide an operational and denotational semantics for it. These will be proven 
equivalent. We furthermore define a very general interpreter in this language, the 
semantics of which will prove to be equivalent to the semantics of object-level 
3APL. 

2 3APL is to be pronounced as “triple-a-p-1” . 

3 In the original version this was a set of plans. 

4 The addition of goals was a recent extension [18]. 

5 A change in the environment is a possible “side effect” of the execution of a basic 
action. 
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For regular procedural programming languages, studying a specific inter- 
preter language is in general not very interesting. In the context of agent pro- 
gramming languages it however is, for several reasons. First of all, 3APL and 
agent-oriented programming languages in general are non-deterministic by na- 
ture. In the case of 3APL for example, it will often occur that several plan 
revision rules are applicable at the same time. Choosing a rule for application 
(or choosing whether to execute an action from the plan or to apply a rule if 
both are possible), is the task of a 3APL interpreter. The choices made, affect the 
outcome of the execution of the agent. In the context of agents, it is interesting 
to study various interpreters, as different interpreters will give rise to different 
agent types. An interpreter that for example always executes a rule if possible, 
thereby deferring action execution, will yield a thoughtful and passive agent. In 
a similar way, very bold agents can be constructed or agents with character- 
istics anywhere on this spectrum. These conceptual ideas about various agent 
types fit well within the agent metaphor and therefore it is worthwhile to study 
an interpreter language and the interpreters that can be programmed in it (see 
also [3]). 

Secondly, as pointed out by Hindriks [7], differences between various agent 
languages often mainly come down to differences in their meta-level reasoning 
cycle or interpreter. To provide for a comparison between languages, it is thus 
important to separate the semantic specification of object-level and meta-level 
execution. 

Finally, and this was the original motivation for this work, we hope that 
the specification of a denotational semantics for the meta-language might shed 
some light onto the issue of specifying a denotational semantics for object-level 
3APL. It however seems, contrary to what one might think, that the denotational 
semantics of the meta-language canuot be used to define a denotational semantics 
for object-level 3APL. We will elaborate on this issue in section 6.2. 

2 Syntax 

2.1 Object-Level 

As stated in the introduction, the latest version of 3APL incorporates beliefs, 
goals and plans. In this paper, we will however consider a version of 3APL with 
only beliefs and plans as was defined in [8] . The reason is, that in this paper we 
focus on the semantics of plan execution, for the treatment of which only beliefs 
and plans will suffice. The language defined in [8] is a first-order language, a 
propositional and otherwise slightly simplified version of which we will use in 
this paper. 

In the sequel, a language defined by inclusion shall be the smallest language 
containing the specified elements. 

Definition 1 . (belief bases) Assume a propositional language C with typical 
formula ip and the connectives A and -i with the usual meaning. Then the set of 
possible belief bases £ with typical element a is defined to be p(£). 
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Definition 2. (plans) Assume that a set BasicAction with typical element a is 
given, together with a set AbstractPlan. The symbol E denotes the empty plan. 
Then the set of plans 77 with typical element n is defined as follows: 

— { E } U BasicAction U AbstractPlan C II, 

— if c £ ({ E } U BasicAction U AbstractPlan) and n £ II then c ; n £ U 6 . 

A plan E\ it is identified with the plan 7 r. 

For reasons of presentation and technical convenience, we exclude non-deter- 
ministic choice and test from plans. This is no fundamental restriction as non- 
determinism is introduced by plan revision rules (to be introduced below) . Fur- 
thermore, tests can be modelled as basic actions that do not affect the state if 
executed (for semantics of basic actions see definition 8) . 

A plan and a belief base can together constitute the so-called mental state 
of a 3APL agent. A mental state can be compared to what is usually called a 
configuration in procedural languages, i.e. a statement-state pair. 

Definition 3. (mental states) Let E be the set of belief bases and let II be the 
set of plans. Then IT x E is the set S of possible mental states of a 3APL agent. 

Definition 4. (plan revision (PR) rules) A PR rule p is a triple 7T/j \ ip irb 
such that ip £ C, 7 r*., 7r& £ II and ^ E. 

Definition 5. (3APL agent) A 3APL agent A is a tuple (7To, <7 o, BasicAction, 
AbstractPlan, Rule, T) where ( 710 , ao) is the initial mental state, BasicAction, 
AbstractPlan and Rule are sets of basic actions, abstract plans and PR rules 
respectively and T : (BasicAction x E) — » E is a belief update function. 

In the following, when referring to agent A, we will assume this agent to have 
a set of basic actions BasicAction, a set of abstract plans AbstractPlan, a set of 
PR rules Rule and a belief update function T. 

2.2 Meta-level 

In this section, we define the meta-language that can be used to write 3APL inter- 
preters. The programs that can be written in this language will be called meta- 
programs. Like regular imperative programs, these programs are state trans- 
formers. The kind of states they transform however do not simply consist of an 
assignment of values to variables like in regular imperative programming, but 
the states that are transformed are 3APL mental states. In section 3.1, we will 
define the operational semantics of our meta-programs. We will do this using 
the concept of a meta-configuration. A meta-configuration consists of a meta- 
program and a mental state, i.e. the meta-program is the procedural part and 
the mental state is the “data” on which the meta-program operates. 

The basic elements of meta-programs are the execute action and the apply(p) 
action (called meta- actions). The execute action is used to specify that a basic 



For technical convenience, plans are defined to have a list structure. 
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action from the plan of an agent should be executed. The apply (p) action is 
used to specify that a PR rule p should be applied to the plan. Composite meta- 
programs can be constructed in a standard way. 

Below, the meta-programs and meta-configurations for agent A are defined. 

Definition 6. (meta-programs) We assume a set Bexp of boolean expressions 
with typical element b. Let b £ Bexp and p £ Rule, then the set Prog of meta- 
programs with typical element P is defined as follows: 

P ::= execute \ apply(p) | while b do P od | Pi; P 2 | Pi + P 2 . 

Definition 7. (meta-configurations) Let Prog be the set of meta-programs and 
let S be the set of mental states. Then Prog x S is the set of possible meta- 
configurations. 

3 Operational Semantics 

In [8], the operational semantics of 3APL is defined using transition systems [11]. 
A transition system for a programming language consists of a set of derivation 
rules for deriving transitions for this language. A transition is a transformation 
of one configuration into another and it corresponds to a single computation 
step. In the following section, we will repeat the transition system for 3APL 
given in [8] (adapted to fit our simplified language) and we will call it the object- 
level transition system. We will furthermore give a transition system for the 
meta-programs defined in section 2.2 (the meta-level transition system). Then 
in the last section, we will define the operational semantics of the object- and 
meta-programs using the defined transition systems. 

3.1 Transition Systems 

The transition systems defined in the following sections assume 3APL agent A. 

Object-Level. The object-level transition system (Trans 0 ) is defined by the 
rules given below. The transitions are labeled to denote the kind of transition. 

Definition 8. (action execution) Let a £ BasicAction. 

T (a, a) = a' 

(u, 7T, (j) > execute ) 

In the next definition, we use the operator •. The statement 7Ti • 112 denotes a 
plan of which 7Ti is the first part and 7T2 is the second, i.e. 7Ti is the prefix of this 
plan. We need this operator because plans are defined to have a list structure 
(see definition 2). 

Definition 9. (rule application) Let p : iTh | if 7p, £ Rule. 

h v 

(jTh • TT) O') > apply(p ) {^b • ^ ^") 
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Meta-level. The meta-level transition system (Trans m ) is defined by the rules 
below, specifying which transitions from one meta-configuration to another are 
possible. As for the object-level transition system, the transitions are labelled to 
denote the kind of transition. 

An execute meta-action is used to execute a basic action. It can thus only be 
executed in a mental state, if the first element of the plan in that mental state is 
a basic action. As in the object-level transition system, the basic action a must 
be executable and the result of executing a on belief base a is defined using 
the function T. After executing the meta-action execute , the meta-program is 
empty and the basic action is gone from the plan. Furthermore, the belief base 
is changed as defined through T. 

Definition 10. (action execution) Let a £ BasicAction. 

T (a, a) = a' 

(< execute , (a; n, a)) -> execute ( E , (7 r, a')) 

A meta-action apply(p) is used to specify that PR rule p should be applied. It 
can be executed in a mental state if p is applicable in that mental state. The 
execution of the meta-action in a mental state results in the plan of that mental 
state being changed as specified by the rule. 

Definition 11. (rule application) Let p : ith | if G Rule. 

<y_ h ^ 

(apply (p), (n h • 7 r, a)) -+ ap piy(p) (E, (7 r b • 7 r, a)) 

In order to define the transition rule for the while construct, we first need to 
specify the semantics of boolean expressions Bexp. 

Definition 12. (semantics of boolean expressions) We assume a function W of 
type Bexp — > (S — > W) yielding the semantics of boolean expressions, where W 
is the set of truth values {tt, jf} with typical formula f3. 

The transition for the while construct is then defined in a standard way below. 
The transition is labeled with idle, to denote that this is a transition that does 
not have a counterpart in the object-level transition system. 

Definition 13. (while) 



W(b)(a) 

(while b do P od, s) — > idle (P; while b do P od, s) 

-.W(6)(a) 

(while b do P od, s) — >idi e (Ei s) 

The transitions for sequential composition and non-deterministic choice are de- 
fined as follows in a standard way. The variable x is used to pass on the type of 
transition through the derivation. 
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Definition 14. (sequential composition) Let x £ {ex ecute, apply (p), idle \ p € 

Rule}. 

(Pi,s) -+ x (Pis') 

(Pi;P 2 ,s) (P[-,P 2 ,s') 

Definition 15. (non- deterministic choice) Let x £ {execute, apply (p), idle \ 

p £ Rule}. 

(Pus) (P{,s') ( P 2 ,s ) x ( P* 2 ,s ') 

(Pi +P2,S) (P{ , S') (Pi + P 2 , S ) (P(_ , S') 

3.2 Operational Semantics 

Using the transition systems defined in the previous section, transitions can be 
derived for 3APL and for the meta-programs. Individual transitions can be put 
in sequel, yielding so called computation sequences. In the following definitions, 
we define computation sequences and we specify the functions yielding these 
sequences, for the object- and meta-level transition systems. We also define the 
function k, yielding the last element of a computation sequence if this sequence 
is finite and the special state _L otherwise. These functions will be used to define 
the operational semantics. 

Definition 16. (computation sequences) The sets S + and S°° of respectively 
finite and infinite computation sequences are defined as follows: 

S + = {si, | Si £ S, 1 < i < n, n £ N}, 

S°° = {si, . . . ,Si, . . . | Sj € S', ieN}. 

Let Sj_ = SU{1} and S £ S + U S°°. The function k : (S + U S°°) — > Sj_ is 
defined by: 

~(x\ — f l as<: e l emen t of 6 if S £ S+, 

} _L otherwise. 

The function k is extended to handle sets of computation sequences as follows: 
n({8i | i £ I}) = {K(Si) | i £ I}. 

Definition 17. (functions for calculating computation sequences) The functions 
C 0 and C m are respectively of type S — > p(S + U S°°) and Prog — > (S — > p(S + U 
S°°)). 

Co(s ) — {^ 1 ? • • • ? s n 

{si, . . . , Si, 

C m (P)(s) = {Si, ...,S n 

}si, . . . , Si, 



£ p(S + ) | S -> tl Si ->t 2 • • • —>t n (E, On) 

is a finite sequence of transitions in Trans 0 } U 
■ ■ ■ £ p(S ) | s Si > t 2 • • • *ti Sj >ti + 1 • • • 

is an infinite sequence of transitions in Trans 0 } 
e p(S + ) I (P, s) -> Xl (Pi, Sl) ~^x 2 ■ ■ ■ —>x n ( E , S n ) 
is a finite sequence of transitions in Trans m } U 
• ••ep(S°°) | (P,s) (P 1)Sl ) -» I2 ... 

>Xi (Pii s i) *Xi + 1 • • • 

is an infinite sequence of transitions in Trans m } 
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Note that both C 0 and C m return sequences of mental states. C 0 just returns the 
mental states comprising the sequences of transitions derived in Trans 0 , whereas 
C m removes the meta-program component of the meta-configurations of the tran- 
sition sequences derived in Trans m . The reason for defining these functions in 
this way is, that we want to prove equivalence of the object- and meta-level 
transition systems: both yield the same transition sequences with respect to the 
mental states (or that is for a certain meta-program, see section 4). Also note 
that for C 0 as well as for C m , we only take into account infinite sequences and 
successfully terminating sequences, i.e. those sequences ending in a mental state 
or meta-configuration with an empty plan or meta-program respectively. 

The operational semantics of object- and meta-level programs are functions 
O 0 and Om, yielding, for each mental state s and possibly meta-program P, a set 
of mental states corresponding to the final states reachable through executing 
the plan of s or executing the meta-program P respectively. If there is an infinite 
execution path, the set of mental states will contain the element _L. 

Definition 18. (operational semantics) Let s £ S. The functions 0 0 and O m 
are respectively of type S± — > p(Sj_) and Prog — > ( S± — + p(S±)). 

O 0 (s) = k(C 0 (s)) 

O m (P)(s) = K(C m (P)(s)) 

Oo(±) =O m (P)(±) = {J_} 

Note that the operational semantic functions can take any state s £ S±, includ- 
ing _L, as input. This will turn out to be necessary for giving the equivalence 
result of section 6. 

4 Equivalence of O 0 and O m 

In the previous section, we have defined the operational semantics for 3APL and 
for meta-programs. Using the meta-language, one can write various 3APL inter- 
preters. Here we will consider an interpreter of which the operational semantics 
will prove to be equivalent to the object-level operational semantics of 3APL. 
This interpreter for agent A is defined by the following meta-program. 

Definition 19. (interpreter) Let UT=i Pi — Rule, s £ S and let notEmptyPlan 
£ Bexp be a boolean expression such that W (not Empty PI an) (s) = tt if the plan 
component of s is not equal to E and W(notEmptyPlan)(s) = ff otherwise. 
Then the interpreter can be defined as follows. 

while notEmptyPlan do ( execute + apply(pi) + . . . + apply(p n )) od 

In the sequel, we will use the keyword interpreter to abbreviate this meta-pro- 
gram. 

This interpreter thus iterates the execution of a non-deterministic choice between 
all basic meta-actions, until the plan component of the mental state is empty. 
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Intuitively, if there is a possibility for the interpreter to execute some meta-action 
in mental state s, resulting in a changed state s', it is also possible to go from s 
to s' in an object-level execution through a corresponding object-level transition. 
At each iteration, an executable meta-action is non-deterministically chosen for 
execution. The interpreter thus as it were, non-deterministically chooses a path 
through the object-level transition tree. The possible transitions defined by this 
interpreter correspond to the possible transitions in the object-level transition 
system and therefore the object-level operational semantics is equivalent to the 
meta-level operational semantics of this meta-program 7 . 

Theorem 1. (O a = O m ( Interpreter^ 

Vs G S : Oo(s) = O m (interpreter) (s) 

Proof. We prove a weak bisimulation (see [17]). 

Note that it is easy to show that O a = O m {P) does not hold for all meta- 
programs P. 

5 Denotational Semantics 

In this section, we will define the denotational semantics of meta-programs. The 
method used is the fixed point approach as can be found in Stoy [15]. The 
semantics greatly resembles the one in De Bakker ([4], Chapter 7) to which we 
refer for a detailed explanation of the subject. 

A denotational semantics for a programming language in general, is, like an 
operational semantics, a function taking a statement P and a state s and yielding 
a state (or set of states in case of a non-deterministic language) resulting from 
executing P in s. The denotational semantics for meta-programs is thus, like 
the operational semantics of definition 18, a function taking a meta-program P 
and mental state s and yielding the set of mental states resulting from executing 
P in s, i.e. a function of type Prog — > (S± —> p(S±)) 8 . Contrary however 
to an operational semantic function, a denotational semantic function is not 
defined using the concept of computation sequences and, in contrast with most 
operational semantics, it is defined compositionally [16, 10,4]. 

5.1 Preliminaries 

In order to define the denotational semantics of meta-programs, we need some 
mathematical machinery. Most importantly, the domains used in defining the 

7 The result only holds if PR rules of the form E \ ip nb are excluded from the 
set of rules under consideration, as was specified in definition 4. A relaxation of this 
condition would call for a slightly different interpreter to yield the equivalence result. 
For reasons of space and clarity, we will however not discuss this possibility here. 

8 The type of the denotational semantic function is actually slightly different as will 
become clear in the sequel, but that is not important for the current discussion. 
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semantics of meta-programs are designed as so-called complete partial orders 
(CPO’s). A CPO is a set with an ordering on its elements with certain charac- 
teristics. We assume the reader is familiar with the notions of partially ordered 
sets, least upper bounds and chains, in terms of which the concept of a CPO is 
defined. For a rigorous treatment of the subject, we refer to De Bakker [4], 

Definition 20. ( CPO) A complete partially ordered set is a set C with a partial 
order C which satisfies the following requirements: 

1. there is a least element with respect to C, i.e. an element i £ C such that 
Vc G C : 1 C c, 

2. each chain (cj)£2. 0 in C has a least upper bound (|J°1 0 c,) £ C. 

The semantics of meta-programs will be defined using the notion of the least 
fixed point of a function on a CPO. 

Definition 21. (least fixed, point) Let (C, C) a CPO, / : C — > C and let x € C. 

— x is a fixed point of / iff f(x) = x 

— x is a least fixed point of / iff x is a fixed point of / and for each fixed point 
V of /: x C y 

The least fixed point of a function / is denoted by pf. 

Finally, we will need the following definition and fact. 

Definition 22. (continuity) Let (Ci, Ci), {C 2 , C 2 ) be CPO’s. Then a function 
/ : Ci — ■> C 2 is continuous iff for each chain (ci)fl 0 in Ct, the following holds: 

/(U“ 0 o) = U=o/(o). 

Fact 1. (fixed point theorem) Let C be a CPO and let / : C —> C. If / is 
continuous, then the least fixed point pf exists and equals |_|°1 0 where 

/°(-L) = -L and / i+1 (J_) = /(/*(±)). 

For a proof, see for example De Bakker [4] . 

5.2 Definition 

We will now show how the domains used in defining the semantics of meta- 
programs are designed as CPO’s. The reason for designing these as CPO’s will 
become clear in the sequel. 

Definition 23. (domains of interpretation) Let W be the set of truth values of 
definition 12 and let S be the set of possible mental states of definition 3. Then 
the sets W± and SA are defined as CPO’s as follows: 

W± = W U {Cw } CPO by fit C fi 2 iff fit = _L W or fit = fi 2 , 

S± = S U {T} CPO analogously. 
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Note that we use _L to denote the bottom element of S± and that we use _L c 
for the bottom element of any other set C. As the set of mental states is ex- 
tended with a bottom element, we extend the semantics of boolean expressions 
of definition 12 to a strict function, i.e. yielding _l_w for an input state _L. 

In the definition of the denotational semantics, we will use an if-tlren-else 
function as defined below. 

Definition 24. (if-then-else) Let C be a CPO, ci,C 2 ,J-c € C and (3 € W±. 
Then the if-then-else function of type W± — > C is defined as follows. 



| ci if f3 = tt 
if (3 then Ci else C 2 fi = ^ C 2 if (3 = jf 

[ j-c if [3 = -L w 

Because our meta-language is non-deterministic, the denotational semantics is 
not a function from states to states, but a function from states to sets of states. 
These resulting sets of states can be finite or infinite. In case of bounded non- 
determinism 9 , these infinite sets of states have T as one of their members. This 
property may be explained by viewing the execution of a program as a tree 
of computations and then using Konig’s lemma which tells us that a finitely- 
branching tree with infinitely many nodes has at least one infinite path (see 
[4]). The meta-language is indeed bounded non-deterministic 10 and the result of 
executing a meta-program P in some state, is thus either a finite set of states or 
an infinite set of states containing _L. We therefore specify the following domain 
as the result domain of the denotational semantic function instead of p(Sj_). 

Definition 25. (T ) The set T with typical element r is defined as follows: 
T = {t £ p(S_ l) | r finite or 1 £ r}. 

The advantage of using T instead of p(Sj_) as the result domain, is that T can 
nicely be designed as a CPO with the following ordering [5] . 

Definition 26. (Egli-Milner ordering) Let ti,T 2 £ T. T\ C r 2 holds iff either 
1 £ T\ and n \ {T} C T 2 , or J_ ^ n and n = 72 . Under this ordering, the set 
{J_} is ± T . 

We are now ready to give the denotational semantics of meta-programs. We will 
first give the definition and then justify and explain it. 

Definition 27. (denotational semantics of meta-programs) Let 4>i,4>2 ■ S± — > 
T. Then we define the following functions. 

<i> : T -> T = At ■ (J s6t <j>(s) 

4>i ° <t >2 ■ S± -» T = As • (j>i(<f> 2 (s)) 

9 Bounded non-determinism means that at any state during computation, the number 
of possible next states is finite. 

10 Only a finite number of rule applications and action executions are possible in any 
state. 
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Let ( 7 r, a) £ S. The denotational semantics of meta-programs M : Prog 
(S± — > T) is then defined as follows. 



A4 [execute] (n, 0 ) 

A i[execute\ _L 

M[apply{p)]{-K,o) 

M\apply{p)\ _L 
Ad [while b do P od] 
M[P 1 -,P 2 ] 

m[p 1 + p 2 ] 



10 

J -T 



if 7T = a; 7r' 

with a £ BasicAction and T(a, o) = o' 
otherwise 



{(7T 6 0 7r', 

0 



0 ) } if cr |= ip and n = o n' 
with p : TTh | 70 TTfc £ Rule 
otherwise 



J -T 



Ad[P 2 ] o Ad[Pi] 
Ad [Pi] U A4[P 2 ] 



The function <P : ( S± — » T) — > (Sj_ — » T) used above is defined as 
X(j> ■ As • if W(6)(s) then (/>(Ad[P](s)) else {s} f i, using definition 24. 



Meta-actions. The semantics of meta-actions is straight forward. The result 
of executing an execute meta-action in some mental state s, is a set containing 
the mental state resulting from executing the basic action of the plan of s. The 
result is empty if there is no basic action on the plan to execute. The result of 
executing an apply(p) meta-action in state s, is a set containing the mental state 
resulting from applying p in s. If p is not applicable, the result is the empty set. 



While. The semantics of the while construct is more involved, but we will only 
briefly comment on it. For a detailed treatment, we again refer to De Bakker [4]. 

What we want to do, is define a function specifying the semantics of the 
while construct A4 [while b do P od], the type of which should be S± — > T, in 
accordance with the type of A4 . The function should be defined compositionally, 
i.e. it can only use the semantics of the guard and of the body of the while. 
This is required for A4 to be well-defined. 

The requirement of compositionality is satisfied, as the semantics is defined 
to be the least fixed point of the operator which is defined in terms of the 
semantics of the guard and body of the while. 

The least fixed point of an operator does not always exist. By the fixed point 
theorem however (fact 1), we now that if the operator is continuous (definition 
22), the least fixed point does exist and is obtainable within lo steps. By proving 
that <P is continuous, we can thus conclude that pd> exists and therefore that A4 
is well-defined. 

Theorem 2. (continuity of d>) The function <P as given in definition 27 is con- 
tinuous. 

Proof. For a proof, we refer to [17]. The proof is analogous to continuity proofs 
given in [4] . 
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Note that in the definition of <£, the function <f> is of type S± — » T and M. |P](s) € 
T. This cf) can thus not be applied directly to this set of states in T, but it must 
be extended using the * operator to be of type T T. 

Sequential Composition and Non-deterministic Choice. The semantics 
of the sequential composition and non-deterministic choice operator is as one 
would expect. 

6 Equivalence of Meta-level Operational 
and Denotational Semantics 

In this section, we will state that the operational semantics for meta-programs 
is equal to the denotational semantics for meta-programs and we will relate this 
to the equivalence result of section 4. We will furthermore discuss the issue of 
defining a denotational semantics for object-level 3APL. 



6.1 Equivalence Theorem 

Theorem 3. (O m = M. ) Let O m : Prog — » (S± — > p(£j_)) be the operational 
semantics of meta-programs (definition 18) and let A4 : Prog — > (Sj_ — > T) be 
the denotational semantics of meta-programs (definition 27). Then, the following 
equivalence holds for all meta-programs P £ Prog and all mental states s £ S±. 

O m (P)(s) = M(P)(s) 

Proof. For a proof, we refer to [17]. The proof is constructed using techniques 
from Kuiper [9] . 

In section 4, we stated that the object-level operational semantics of 3APL is 
equal to the meta-level operational semantics of the interpreter we specified in 
definition 19. Above, we then stated that it holds for any meta-program that 
its operational semantics is equal to its denotational semantics. This holds in 
particular for the interpreter of definition 19, i.e. we have the following corollary. 

Corollary 1. (0 0 = A4 (interpreter^ From theorems 1 and 3 we can conclude 
that the following holds. 

O a = Al(interpreter) 



6.2 Denotational Semantics of Object-Level 3APL 

Corollary 1 states an equivalence between a denotational semantics and the 
object-level operational semantics for 3APL. The question is, whether this deno- 
tational semantics can be called a denotational semantics for object-level 3APL. 

A denotational semantics for object-level 3APL should be a function taking 
a plan and a belief base and returning the result of executing the plan on this 
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belief base, i.e. a function of type 77 — » (S± — » p(E±)) or equivalently 11 , of 
type (77 x if) — + p(E±). The type of Ad(interpreter), i.e. S± — > p(Sj_) 12 , does 
not match the desired type. This could however be remedied by defining the 
following function. 

Definition 28. (A f) Let snd be a function yielding the second element, i.e. the 
belief base, of a mental state in S and yielding fj for input _L. This function 
is extended to handle sets of mental states through the function “ , as was done 
in definition 27. Then Af : S± — » p(E j_) is defined as follows. 

Af = As ■ snd(M [interpreter] (s)) 

Disregarding a _L input, the function Af is of the desired type (77 x if) — + p(E j_). 
The question now is, whether it is legitimate to characterize the function Af as 
being a denotational semantics for 3APL. The answer is no, because a deno- 
tational semantic function should be compositional in its program argument, 
which in this case is 77. This is obviously not the case for the function Af and 
therefore this function is not a denotational semantics for 3APL. 

So, it seems that the specification of the denotational semantics for meta- 
programs cannot be used to define a denotational semantics for object-level 
3APL. The difficulty of specifying a compositional semantic function is due to 
the nature of the PR rules: these rules can transform not just atomic statements, 
but any sequence of statements. The semantics of an atomic statement can thus 
depend on the statements around it. We will illustrate the problem using an 
example. 

a b 
fr; c d 
c ~^> e 

Now the question is, how we can define the semantics of a; cl Can it be defined 
in terms of the semantics of a and cl The semantics of a would have to be 
something involving the semantics of b and the semantics of c something with 
the semantics of e, taking into account the PR rules given above. The semantics 
of a; c should however also be defined in terms of the semantics of d , because 
of the second PR rule: a; c can be rewritten to b; c, which can be rewritten to 
d. Moreover, if b is not a basic action, the third rule cannot be applied and the 
semantics of e would be irrelevant. So, although we do not have a formal proof, 
it seems that the semantics of the sequential composition operator 13 of a 3APL 
plan or program cannot be defined using only the semantics of the parts of which 
the program is composed. 

Another way to look at this issue is the following. In a regular procedural 
program, computation can be defined using the concept of a program counter. 
This counter indicates the location in the code, of the statement that is to be 

11 For the sake of argument, we for the moment disregard alj input. 

12 Af (interpreter) is actually defined to be of type S± — > T, but T C p(«Sj_), so we may 
extend the result type to p(Sj_)- 

13 Or actually of the plan concatenation operator • 
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executed next or the procedure that is to be called next. If a procedure is called, 
the program counter jumps to the body of this procedure. Computation of a 
3APL program cannot be defined using such a counter. Consider for example 
the PR rules defined above and assume an initial plan a; c. Initially, the program 
counter would have to be at the start of this initial plan. Then, the first PR rule 
is “called” and the counter jumps to 6, i.e. the body of the first rule. According 
to the semantics of 3APL, it should be possible to get to the body of the second 
PR rule, as the statement being executed is b; c. There is however no reason for 
the program counter to jump from the body of the first rule to the body of the 
second rule. 



7 Related Work and Conclusion 

The concept of a meta-language for programming 3APL interpreters was first 
considered by Hindriks [7]. Our meta-language is similar to, but simpler than 
Hindriks’ language. The main difference is that Hindriks includes constructs for 
explicit selection of a PR rule from a set of applicable ones. These constructs were 
not needed in this paper. Dastani defines a meta-language for 3APL in [3]. This 
language is similar to, but more extensive than Hindriks’ language. Dastani’s 
main contribution is the definition of constructs for explicit planning. Using these 
constructs, the possible outcomes of a certain sequence of rule applications and 
action executions can be calculated in advance, thereby providing the possibility 
to choose the most beneficial sequence. Contrary to our paper, these papers do 
not discuss the relation between object-level and meta-level semantics, nor do 
they give a denotational semantics for the meta-language. 

Concluding, we have proven equivalence of an operational and denotational 
semantics for a 3APL meta-language. We furthermore related this 3APL meta- 
language to object-level 3APL by proving equivalence between the semantics of a 
specific interpreter and object-level 3APL. Although these results were obtained 
for a simplified 3APL language, we conjecture that it will not be fundamentally 
more difficult to obtain similar results for full first order 3APL 14 . 

As argued in the introduction, studying interpreter languages of agent pro- 
gramming languages is important. In the context of 3APL and PR rules, it is 
especially interesting to investigate the possibility of defining a denotational or 
compositional semantics, for such a compositional semantics could serve as the 
basis for a (compositional) proof system. It seems, considering the investigations 
as described in this paper, that it will however be very difficult if not impossible 
to define a denotational semantics for object-level 3APL. As it is possible to 
define a denotational semantics for the meta-language, an important issue for 
future research will be to investigate the possibility and usefulness of defining 
a proof system for the meta-language, using this to prove properties of 3APL 
agents. 



14 



The requirement of bounded non-determinism will in particular not be violated. 
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Abstract. We develop an equational definition of exception monads 
that characterizes Moggi’s exception monad transformer. This axiomati- 
zation is then used to define an extension of previously described monad- 
independent computational logics by abnormal termination. Instantiat- 
ing this generic formalism with the Java monad used in the LOOP project 
yields in particular the known Hoare calculi with abnormal termination 
and JML’s method specifications; this opens up the possibility of extend- 
ing these formalisms by hitherto missing computational features such as 
I/O and nondeterminism. 

Introduction 

In the course of efforts to provide proof support for the verification of Java pro- 
grams, the classical Hoare calculus [4] has been extended to encompass exception 
handling in Java [5, 7, 8, 26], the main challenge being to deal with poststates 
of abruptly terminating statements. Exceptions in Java are part of a monad for 
Java [9], following the paradigm of encapsulation of side effects via monads [12]. 
Thus, the question arises whether extended Hoare calculi for exceptions can be 
developed abstractly over any monad with exceptions. We answer this question 
positively by first characterizing Moggi’s exception monad transformer by an 
equational theory based on a categorical formulation, and then extending our 
previous work about monad-independent Hoare calculi [21, 23] to calculi for ex- 
ception monads that take into account both normal and abrupt termination. 
The advantage of such an approach is that it is not bound to a specific com- 
bination of computational effects like the Java monad. Moreover, most of the 
rules of the calculus come essentially for free by just adapting the normal monad 
independent Hoare rules [21, 23] using the equational description of exception 
monads. 

As the background formalism for these concepts, we use the logic of Has- 
Casl, a higher-order language for functional specification and programming, 
which is basically the internal language of partial cartesian closed categories (a 
generalization of toposes). The paper is organized as follows. In Sections 1, 2 
and 3, we recall the HasCasl logic, monads and the logic for monads built on 
top of HasCasl. Section 4 axiomatizes exception monads and proves that they 
characterize Moggi’s exception monad transformer, and Section 5 introduces the 
Hoare logic for exception monads. 
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1 HasCasl 

HasCasl is a higher-order extension of Casl [2], featuring higher-order func- 
tions in the style of Moggi’s partial A-calculus [10], type constructors, type classes 
and constructor classes (for details, see [22, 24]); general recursion is specified on 
top of this in the style of HOLCF. The semantics of a HasCasl specification is 
the class of its (set-theoretic) intensional Henkin models: a function type need 
not contain all set-theoretic functions, and two functions that yield the same 
value on every input need not be equal. 

A consequence of the intensional semantics is the presence of an intuitionistic 
internal logic that lives within A-terms, defined in terms of equality [22]. There is 
built-in syntactical sugar for the internal logic, invoked by means of the keyword 
internal which signifies that formulas in the following block are to be understood 
as formulas of the internal logic. 

Categorically speaking, HasCasl’s Henkin models correspond to models in 
partial cartesian-closed categories (pccc’s) [20], a generalization of toposes [1]. 
Basic HasCasl can be seen as syntactic sugar over the internal language of a 
pccc, i.e. essentially intuitionistic higher order logic of partial functions. 



2 Monads for Computations 

On the basis of Moggi’s seminal work [12], monads are being used in both se- 
mantics and programming to formalize and encapsulate side effects in an elegant, 
functional way. Intuitively, a monad associates to each type A a type T A of com- 
putations of type A ; a function with side effects that takes inputs of type A and 
returns values of type B is, then, just a function of type A —> TB, also called 
a (B -valued) program. This approach abstracts away from particular notions of 
computation such as store, non-determinism, non-termination etc.; a surpris- 
ingly large amount of reasoning can in fact be carried out independently of the 
choice of such a notion. 

More formally, a monad on a given category C can be presented as a Kleisli 
triple T = ( [T , r], _*), where T : Ob C — > Ob C is a function, the unit ?y is a family 
of morphisms t/a '■ A — > T A, and _* assigns to each morphism / : A — > TB a 
morphism f* : TA — > TB such that 

Va = id T A, f*VA = f, and g* f* = (g * /)* . 

This description is equivalent to the more familiar one via an endofunctor T 
with unit ?y and a multiplication p [1]. A monad defines its Kleisli category, 
which has the same objects as C and ‘functions with side effects’ / : A — > TB 
as morphisms from A to B\ the Kleisli composite of two such functions g and / 
is just g* f . 

In order to support a language with finitary operations and multi-variable 
contexts (see below), one needs a further technical requirement: a monad is called 
strong if it is equipped with a natural transformation 

t a,b '■ A x TB — > T(A x B ) 

called strength, subject to certain coherence conditions. 
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Example 1 ([12]). Computationally relevant monads on Set (all monads on 
Set are strong) include 

— stateful computations with possible non-termination: TA = (S — >? (A x S')), 
where S is a fixed set of states and _ — >? _ denotes the partial function type; 

— (finite) non-determinism: TA = Vfi n (A), where Vfi„ denotes the finite power 
set functor; 

— exceptions: T A = A + E, where E is a fixed set of exceptions; 

— interactive input: TA is the least fixed point of Ay .A + (U —>? 7 ), where U 
is a set of input values. 

— non-deterministic stateful computations: TA = S — > Vfi n (A x S), where, 
again, S is a fixed set of states; 

Reasoning about a category C equipped with a strong monad is greatly 
facilitated by the fact that proofs can be conducted in an internal language [ 12 ]. 
The crucial features of this language are 

— A type operator T, where, as above, TA contains computations of type A; 

— a polymorphic operator ret : A — > T A corresponding to the unit; 

— a binding construct, which we denote in Haskell’s do style instead of by let: 
terms of the form 

do x <— ei; e 2 

are interpreted by means of the tensorial strength and Kleisli composi- 
tion [12] — e.g. if the ambient context is y : A and ei is T-valued, then the 
interpretation [do x <— ei; e 2 ] is [e 2 ]* o tA.B 0 [[(j/, ei)] . Intuitively, do x <— 
ei ; e 2 computes ei and passes the results on to e 2 . Nested do expressions like 
do x <— ei; do y 4— e 2 ; ... may also be denoted do x 4— ei; y <— e 2 ; . . . . 
Repeated nestings such as do x\ <— ei, . . . , x n <— e„; e are somewhat in- 
accurately denoted in the form do x 4— e; e. Sequences of the form x 4— e 
are called program sequences. Variables ay that are not used later on may be 
omitted from the notation. 

This language (with further term formation rules and a deduction system) can 
be used both in order to define morphisms in C and in order to prove equalities 
between them [12]. Indeed, the theory of exception monads presented in Sec- 
tion 4 is formulated in this internal language, over an arbitrary category with 
equalizers. Only in the context of computational logic (e.g. the Hoare calculus 
introduced in the next section), one needs the framework of a partial cartesian 
closed category (and its internal language, phrased in HasCasl). 

Given a monad, one can generically define control structures such as a while 
loop (see for example [15]). Such definitions require general recursion, which 
is realized in HasCasl by means of fixed point recursion on epos, with the 
associated fixed point operator on continuous endofunctions denoted by Y [22] . 
Thus, one has to restrict to monads, called epo-monads, that allow lifting a epo 
structure on A to a epo structure on the type TA of computations in such a way 
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that the monad operations become continuous. The (executable) specification 
of an iteration construct is shown in Figure 1. The specification imports named 
specifications Bool of the booleans and CpoMonad of cpo-monads; __ -4? and 
__ — » __ are the type constructors for the partial and total continuous function 
space, respectively. The iteration construct behaves like a while loop, except that 
it additionally passes a result value through the iterations. The while loop is just 
iteration ignoring the result value. 



spec Iteration = CpoMonad and Bool then 
vars m : CpoMonad ; a : Cpo 

op iter : (a A m Bool ) A (a A? m a) A a A? m a 
program iter test f x = 
do b <— test x 
if b then 

do y <— f x 
iter test f y 
else return x 

op while{b : m Bool)(p : m Unit) : m Unit = iter (Ax • b) (Ax • p) () 



Fig. 1 . The iteration control structure 



3 Monad-Independent Computational Logic 

We now recall notions of side-effect freeness in monads [21, 25] and the recently 
developed monad-independent computational logics [23, 21]. Throughout, T will 
denote a strong monad. 

Like traditional Hoare logic, the monad-independent Hoare calculus is con- 
cerned with proving Hoare triples consisting of a stateful expression together 
with a pre- and a postcondition. The pre- and postconditions are required to 
‘leave the state unchanged’ in a suitable sense in order to guarantee composabil- 
ity of Hoare triples; they may, however, read the state. 

Definition 2. A program p is called discardable if 

(do y <— p\ ret *) = ret *, 
where * is the unique element of the unit type. 

For example, a program p is discardable in the state monad iff p terminates and 
does not change the state. 

A program p is called stateless if it factors through rj, i.e. if it is just a value 
inserted into the monad — otherwise, it is called stateful. E.g. in the state monad, 
p is stateless iff it neither changes nor reads the state. Stateless programs are 
discardable, but not vice versa. 
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In order to define the semantics of Hoare triples below, we introduce global 
dynamic judgements of the form [x <— p] <f, which intuitively state that <f holds 
after execution of the program sequence x <— p, where <j> is a stateless formula 
(i.e. 4> : 17, where 17 is the type of truth values). Formally, [x <— p] <f abbreviates 

(do x <— p\ ret (x, (f>)) = do x *— p\ ret(x, T). 

Definition 3. A program p is copyable if 

(do x p; y <— p; ret(x, y)) = do x <— p; ret(x, x). 

A program p commutes with a program q if 

(do x*-p\y <- q\ ret(z, y)) = do y <- q\ x <- p\ ret(x, y). 

A discardable and copyable program is called deterministically side-effect free 
(dsef) if it commutes with all (equivalently: all 17-valued) discardable copyable 
programs. For a type A, the subtype of TA consisting of the dsef computations 
is denoted DA. 

Dsef programs are syntactically treated like stateless values; their properties 
guarantee that arising ambiguities correspond to actual equalities. A discardable 
program p is copyable iff it is deterministic in the sense that 

[a p\y +- p\{x = y). 

Stateless programs are dsef. In the monads of Example 1, all discardable pro- 
grams are dsef, with the exception of the monads where non-determinism is 
involved. In these cases, a discardable program is dsef iff it is deterministic. 

Definition 4. A Hoare triple for partial correctness, written {<f} x <— p {if}, 
consists of a program sequence x <— p, a precondition (f> : Df2, and a postcondi- 
tion if : D 17 (which may contain x) . This abbreviates the formula 

[a <— <fi] x <— p; b <— if] a => b. 

For example, a Hoare triple {<f} x *— p {if} holds in the state monad iff, 
whenever <f holds in a state s, then if holds for x after successful execution of p 
from s with result x. In the non-deterministic state-monad, if must be satisfied 
for all possible pairs of results and post-states for p. 

Monad-independent dynamic logic is used in order to also capture Hoare 
triples for total correctness [21]. Dynamic logic allows nesting modal operators 
of the nature ‘after execution of p' and the usual connectives of first order logic. 
This means informally that the state is changed according to the effect of p 
within the scope of the modal operator, but is ‘restored’ outside that scope. 
E.g., in a dynamic logic formula such as 

\p]4> => [q]if, 

the subformulas [p] <j> and [g] ‘if are evaluated in the same state, while (f and if 
are evaluated in modified states. 
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Definition 5 . A formula (of dynamic logic) is a term ip : DQ. The formula <p 
is valid if tp = do x 4— <p] ret T. 

The usual logical connectives are defined using the do-notation. The question is 
now whether DQ has enough structure to allow also the interpretation of the 
diamond and box operators ( p ) and [p] of dynamic logic. 

Definition 6. T admits dynamic logic if there exist, for each program sequence 
y <— q and each formula tp : Df2, a formula [y <— q\ tp such that 

[x <- p] (xi => [y <- q] tp) «=> [x <-p;y <- q\ (xi => tp) 

for each program sequence x <— p containing x^ : ft and, dually, a formula 
(y <— q)tp such that 

[T 4- p] ((y 4- q)tp => Xi ) [x <-p;y<- q] (tp => Xi). 

(Since the internal logic is intuitionistic, one cannot simply define ( y <— q)tp as 
—\y 4— q] -up.) The formulae [y <— q] tp and (y 4— q)tp are uniquely determined. 
A deduction system is obtained as a collection of lemmas in the internal logic. 
Most computational monads, with the exception of the continuation monad, 
admit dynamic logic [21]. 

Hoare triples for partial correctness {tp} p {ip} can be expressed in dynamic 
logic as tp => [p] ip , and we now can also give a meaning to Hoare triples for total 
correctness by interpreting them as partial correctness plus termination: 

[tp\ p [ip] :=<p=> ((p ) T A [p] ip). 

4 Exception Monads 

We now proceed to develop a general treatment of monads that feature excep- 
tions which can be raised and later caught. To begin, we give an equational 
definition in categorical terms, which is then translated into the do-notation. 
In the next section, this definition will be used to formulate Hoare-calculi for 
exception monads. Throughout, T will denote a strong monad. 

There are two essential operations associated to exceptions: an operation 
raise that throws an exception and freezes the state, and a catch operation that 
returns a thrown exception, if any, and unfreezes the state, i.e. resumes normal 
execution of statements. Obvious variations such as an operation that catches 
only certain exceptions (e.g. exceptions only of a given class) and lets others pass 
are easily implemented by combinations of catch and raise. It will be convenient 
to give raise the polymorphic type E — > T A (in the most basic example, raise is 
the right injection E — > A + E) ; of course, the result type A is in fact immaterial 
since raise does not return any results. 

There is a certain amount of disagreement in the literature concerning 
whether raising exceptions should be regarded as a computational feature in its 
own right, or whether exceptions should just be recorded as part of the global 
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state. In the Java semantics developed in the LOOP project, the former approach 
is advocated [6, 9], while the latter option is preferred in [14, 26] (but not in [13], 
motivated by modularity considerations — compare this to Theorem 8 below). 
In terms of concrete monads, the LOOP project [9] uses the monad 

J = XA. (S -> (A x S + E x S + 1)), 

with S the set of states and E the set of exceptions (the parameter A is thought 
of as the type of results), while 



K = XA. ( S E -► {A + 1) x S E + 1) 

is implicitly used in [14, 26], where Se = S x (E + 1), and where the use of 
A + 1 accommodates the fact that abnormally terminating statements do not 
return a value. The monad J is obtained by applying Moggi’s exception monad 
transformer [11] to the usual state monad with non-termination, while K is 
the state monad with non-termination (and possibly undefined results) for the 
extended state set Se- A simultaneous advantage and disadvantage of I\ is that 
catch is a monadic value, i.e. a statement, while in J, catch is a function on 
monadic values, i.e. a control structure. Thus, K contains monadic values that 
arbitrarily manipulate the state even though an exception has been thrown, or 
simultaneously throw an exception and return a value. Consequently, explicit 
Hoare rules are needed to force normal statements to be skipped in exceptional 
states [14, 26]; moreover, it becomes necessary to add normality of the state as 
a precondition to all of the usual Hoare rules. By contrast, in J the state is 
automatically frozen when an exception is thrown. 

We shall model our treatment of generic exception monads along J rather 
than K, precisely because this allows better control over what monadic values 
do. Thus, we need to work with a catch operation of polymorphic type 

TA-> T(A + E), 



which takes a monadic value x and returns a monadic value that executes x 
but terminates normally (if at all), returning either a value returned by x or an 
exception raised by x. 

We are now ready to present the announced categorical definition of exception 
monads. We begin with a short but somewhat mysterious definition and then 
proceed in opposite direction to the heuristics, explicating the definition stepwise 
into a number of intuitively convincing equations. 

Definition 7. An exception monad is a strong monad T, together with a type 
E of exceptions and a natural transformation catch : T — * T(_+ E) such that 



catch 
T 



catch (_+£) 

T(_+E) t T(_+E + E), 

T ini 



is an equalizer diagram of strong monad morphisms. 
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Recall that, given two strong monads S, T on a category C, a (simplified) strong 
monad morphism is a natural transformation a : S — > T, compatible with the 
remaining data in the sense that crp s = p T , er/i S = /i T (cr * a) (where a * a = 
Taas = crrSa), and (t^ax^a = x a ) ( e.g ■ [11])- Naturality of a and 
compatibility with p are, in terms of the associated Kleisli triples (T, p T ,_*) 
and (S, 77 s , _ + ), equivalent to af* = (af) + a, i.e. a is compatible with binding. 

Next, let us point out which parts of Definition 7 are self-understood. Given 
a strong monad T, the functor T(_ + E) is made into a strong monad by taking 
p T ini : A —> T(A + E ) as the unit, and a binding operator that transforms 
f : A T(B + E) into [f,rjinr]* : T(A + E) — * T(B + E ); this is Moggi’s monad 
transformer for exceptions [11] as implemented in the Haskell libraries [15] (of 
course, this presupposes that A + E exists for all A). It is easy to check that 
T ini : T — > T (_ + E) is a strong monad morphism. 

Thus, the actual conditions imposed by the definition are in particular 

— catch : T —> T(_ + E) is a strong monad morphism. Compatibility with 
binding amounts to the equation 

catch f* = [catch f , rj inr}* catch . 



We will see that this expresses the fact that in a sequential statement p\ q , 
either p raises an exception, which is then passed on, and q is skipped, or p 
terminates normally and then q is executed. Compatibility of catch with the 
unit states that pure values do not throw exceptions: catch p = p ini. 

— catchy + e) catch = ( T ini) catch : this equation states that catch does not 
itself raise exceptions. 

Finally, the fact that catch not only equalizes catch/ _ + e) and T ini , but is indeed 
their equalizer, can be captured equationally by means of the raise operation, 
which is conspicuously absent from the basic definition. Indeed we can construct 
this operation: we have a morphism rj : _ + E — > T(_ + E), which equalizes 
catch(_ + E) and T ini because catch is a monad morphism. Thus, we obtain a 
factorization catch f = p, where / is necessarily of the form [??,•]; the raise 
operator is defined as the second component of this morphism: 



T - 

[ 77 , raise] 

-+E 



catch 



T (_ + E) 




- i.e. the defining property of raise is the equation 



catch raise = p inr 



(1) 



stating that raised exceptions are actually caught. In combination with binding 
compatibility of catch, this implies 



catch [p, raise]* = T(_+ V) catch(_ + E), 



(2) 
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where V denotes the codiagonal E+E — > E; note that T (_+V) : T ( _+E+E ) — > 
T ( _+E ) is a strong monad morphism. From this equation, in turn, we can derive, 
using the fact that catch is monic, that 

[?7 , raise]* catch = id (3) 



i.e. catching an exception can be undone by re-raising it. 

Equations 2 and 3, together with the fact that catch equalizes catch (_+e) 
and T ini and the obvious equation T (_ + V) T ini = id , amount to stating that 



T 



catch 



[77, raise]* 



catch (_ + /.y 

T(_+£) r(- + V) T{_+E + E), 
T ini 



is a split equalizer diagram [1] of strong monad morphisms. Thus, we can equiv- 
alently describe an exception monad by means of equations 1 and 3 (the latter 
implies that catch is monic), together with the fact that catch is a strong monad 
morphism (since catch is monomorplric, it follows easily that [ 77 , raise]* is also a 
strong monad morphism) and equalizes catch(_ + E) and T ini. 

The arising purely equational presentation of exception monads can be trans- 
lated into the do-notation as explained in Section 2; the corresponding HasCasl 
specification is shown in Figure 2. The two imported specifications are the specifi- 
cation Monad of monads as described in Section 2 and a specification SumType 
which provides + as an infix sum type operator, with left and right injections 
ini and inr. The axioms (catch-ret) and (catch-seq) state that catch is a strong 
monad morphism (where (catch-seq) covers compatibility with binding as well 
as with the strength). Axiom (catch-raise) is Equation 1 above, (catch-catch) 
states that catch equalizes catch (_ + e) and T ini , and (catchN) is Equation 3. 

In the notation given in Figure 2, it becomes even more evident that all these 
axioms are properties that one would intuitively expect of raise and catch. In 
fact, as indicated above, the given equations come heuristically before Defini- 
tion 7. Other expected properties follow; e.g., (catchN), (catch-seq), and (catch- 
raise) imply that ‘nothing happens after an exception is raised’, i.e. that 

(do x <— raise e; p) = raise e. (4) 

An obvious way to construct exception monads is to use Moggi’s exception 
monad transformer as described above, i.e. to take T = R(_ + E) for a strong 
monad R, with 

catch : R (_ + E) — > R ((_ + E) + E) 

being Rinl. Surprisingly, this construction indeed classifies exception monads: 

Theorem 8. Let C be a category with equalizers. Then every exception monad 
on C is of the form R (_ + E) for some strong monad R on C. 

Proof. Let T be an exception monad, and let R be the equalizer of the morphisms 

catch , T ini : T — + T (_ + E). 
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spec Exception = Monad and SumType then 




types E : Type , Ex : Monad 

var a, b : Type 

ops raise : E — > Ex Unit ; 




catch : Ex a — > Ex (a + E)\ 




internal) 

forall e: E-, p: Ex a; q: a — > Ex b ; 




• catch (do x <— p; q x) = 




do y <— catch p\ case y of ini a — > catch q a 




| inr e — * ret ( inr e) 


% (catch- seq)% 


• catch ( ret x ) = ret ( ini x) 


%(catch-ret)% 


• catch (raise e) = ret (inr e ) 


% (catch-raise) % 


• catch (catch p) = do y <— catch p\ ret (ini y) 

• p = do y <— catch p; case y of ini x —> ret x 


% ( catch- catch ) % 


| inr e — > raise e 

} 


%(catchN)% 



Fig. 2. Equational specification of exception monads 



This equalizer is preserved by the exception monad transformer A M. M (_+ E), 
so that f? (_ + E) =T. 

Thus, our definition of exception monads can be regarded as a complete equa- 
tional characterization of the exception monad transformer. It may appear at 
first sight that this result is illicitly built into the definition, since the codomain 
of catch is T(_+ E). However, this is not the case: the result type of catch de- 
scribes how exceptions are observed , and in this sense constitutes rather a mini- 
mal expectation. By contrast, the theorem above concerns the entirely different 
question of how exceptions are represented in computations, and the answer is 
not at all self-understood. One of its implications is that exceptions are never 
inextricably entwined with other notions of computation — they can always be 
regarded as added to the remaining computational features in a modular way. 

The classification theorem can also be used to facilitate reasoning about 
exception monads; e.g. one can prove: 

Corollary 9. If T is an exception monad and p : TA is a dsef computation, 
then p terminates normally , i.e. catch p = (T inl)p. 

(However, discardable computations may raise exceptions!). 

Notation. In order to have intermediate results of a program sequence x <— p 
available after a catch , the latter must be packaged up and explicitly returned. 
For this procedure, an abbreviated notation comes in handy: catch x *— p denotes 
catch (do x <— p\ retie). 

Remark 10. One subtlety that we have omitted from the development so far 
is the fact that monad-independent computational logic [21, 23] uses a strength- 
ened version of monads in the sense that binding is required to extend also to 
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partial morphisms, i.e. one has /* for / partial. The unit laws for partial bind- 
ing state that f*p agrees with / on the domain of / and behaves like / under 
binding (i.e. (/*??)* = /*). 

The results obtained so far are adapted to this setting as follows. Slightly sur- 
prisingly, the correct definition of a morphism cr of monads with partial binding 
turns out to require, in the notation used above, that the equation of* = ( af) + a 
holds strongly, i.e. as an equation between partial morphisms. Then the arising 
abstract definition of partial exception monads unravels in the same way as 
above. In particular, the only equation in Figure 2 that actually involves partial 
binding, (catch-seq), becomes a strong equation (to be read ‘one side is defined 
iff the other is, and then both sides are equal). Moreover, the exception monad 
transformer indeed transforms monads with partial binding into monads with 
partial binding, and the analogue of Theorem 8 holds in categories with a notion 
of partial morphism, i.e. in dominional categories [19] with equalizers. 

4 A Generic Hoare Calculus with Abrupt Termination 

We now proceed to extend the partial and total generic Hoare calculi for monadic 
programs introduced in Section 2 to take into account exceptional termination, 
thus generalizing similar calculi [5, 7, 8]. The reason that the basic version of 
the generic Hoare calculus is insufficient for purposes of exceptional termination 
is that, due to Equation 4 above, we have 

UM-L} 

whenever p raises an exception (indeed, this holds also e.g. in the ‘normal’ part 
of the calculi of [5, 7]). Thus, no reasonable statements can be made about what 
happens when an exception is raised. We remedy this problem by introducing 
an additional postcondition for exceptional termination, called the abnormal 
postcondition in opposition to the usual postcondition now called the normal 
postcondition. 

This might raise the suspicion that the Hoare calculi of [21, 23] are in fact 
‘insufficiently generic’, and that in reality every new computational feature re- 
quires a whole new Hoare calculus. Besides the examples given in [21, 23], the 
following heuristic argument supports our claim that this is not the case: the 
problem ‘ { } raise e {T}’ quoted above is due to the fact that exceptions are 
constants in the ambient monad, so that exceptional computations of type fl do 
not actually contain any truth values. This phenomenon is unique to constant 
operations, and the only computational interpretation of constants known so far 
is precisely as exceptions. Thus, it appears that the need for substantially (i.e. 
other than in terms of additional axioms and rules for monad-specific program 
constructs) extended Hoare calculi will be limited to the case of exceptions. 

We begin by introducing a partial Hoare calculus for abnormal termination in 
an exception monad T. A corresponding total Hoare calculus, which like the total 
Hoare calculus for normal termination requires additional assumptions on the 
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monad, will be treated further below. We denote the combination of precondition 
and normal and abnormal postcondition in the form 

{(/>} x {ip || 5}, 

where the normal postcondition ip is a stateful formula that may contain the 
result variables x, while the abnormal postcondition S is stateful predicate on 
E (i.e. a function E Ti 1) and cannot use x. This restriction reflects the fact 

that exceptional computations do not have a result; instead, the abnormal post- 
condition is concerned with a hitherto anonymous exception. The interpretation 
of such an extended Hoare assertion is that, if the program sequence x <— p is 
executed in a state that satisfies <p, then if the execution terminates normally, 
the post-state and the result x satisfy ip, and if the execution terminates abnor- 
mally with exception e, the post-state satisfies S e. Formally, {<p} x +— p {ip || S} 
abbreviates 

{<p} y <— ( catch x <— p) {case y of ini x — > ip \ inr e — » S e}. 

The associated Hoare calculus subsumes the generic Hoare calculus [23], since 
one can show that 



{4>} x <- p {ip} <=> {cp} x*-p {ip || T}. 

Figure 3 shows a set of proof rules for extended Hoare assertions. Most of the 
rules except (catch) and (raise) have counterparts in the ‘normal’ generic Hoare 
calculus; note in particular the single composition rule (seq), which is similar 
to the one given in [8]. In the conjunction and weakening rules, notations such 
as Si A S 2 stand for the pointwise operations, here: Ae : E. (Si e) A (S 2 e). The 
(Y) rule refers to the fixed-point operator Y (cf. Section 2); this rule applies 
only to cpo-monads. Application of the Y operator to F requires implicitly that 
F has the continuous function type (A (A —>?TB). The square 

brackets indicate reasoning with local assumptions, discharged by application of 
the rule. Soundness of the rule is a consequence of the fact that satisfaction of 
extended Hoare assertions is an admissible predicate. Using this rule, one easily 
derives rules for particular recursive functions, e.g. the usual while rule or a 
corresponding rule for the iteration construct described in Section 2, 

{(p x A (b ;r)| y <- p x {<p y || S} 

{<p e} y <— iter b p e {(p y A ->(& y) || S} 

(A corresponding rule is listed as a basic rule in the generic Hoare calculus [23], 
which can indeed be improved by moving to a (Y)-like rule.) The exception- 
monad specific rules (catch) and (raise) state that catch catches a thrown excep- 
tion but otherwise does not affect the enclosed program, and that raise really 
throws the given exception. 

The calculus is sound w.r.t. the coding of Hoare triples as formulas in the 
internal language: 
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Theorem 11. If an extended Hoare assertion is derivable in an exception 
monad (cpo-monad) by the rules of Figure 3 excluding (including) (Y), then 
the translated formula is derivable in the internal language. 



The proof uses the definition of extended Hoare assertions via standard Hoare 
triples, the generic Hoare rules [23], and the equations of Figure 2. Completeness 
of the calculus is the subject of further research; we conjecture that a complete- 
ness proof for the Hoare logic of [23] will lead to completeness of the extended 
calculus, since each of the equations in Figure 2 is reflected in one of the rules 
of Figure 3. 




Fig. 3. The generic Hoare calculus for partial exception correctness 
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Total extended Hoare assertions for reasoning about total correctness are, as 
in the basic case, encoded in generic dynamic logic [21]; this requires additionally 
that the monad admits dynamic logic. In this respect, exceptions do not cause 
additional problems: 

Theorem 12. If a strong monadT admits dynamic logic, then so doesT (_+E). 

If an exception monad T admits dynamic logic, then we can define combined 
total correctness assertions for normal and abnormal termination by 

[</)} x <— p [if || S] := {4>} x <— p {if || S} A ( catch p) T. 

A Hoare calculus for such extended total Hoare assertions can be derived from 
the equational axioms for exception monads by means of the proof system for 
generic dynamic logic [21]. As in the basic case, the rules are essentially the same 
as for extended partial Hoare assertions, with the exception of the (Y) rule (and, 
of course, the rules for constructs such as while and iter derived from it). In fact, 
there does not seem to be an immediately obvious total analogue of (Y); however, 
one can easily prove e.g. a total Hoare rule for iter (which then specializes to a 
corresponding total while rule (while-total) by taking while b p = iter bp ()): 

t : A -> DB 

B x B — > Q is well-founded 

[<t> x A b x A (t x = z)\ y ^p x [<f y A (t y < z) || S) 

(iter-total) — — r — — , ,, 

{</> e} y iter b p e {<f y A -i (b y ) || 5) 

In JML, the effect of a statement is specified by giving clauses for the precon- 
dition (assumes), the normal postcondition (ensures), the abnormal postcondi- 
tion (signals), and a precondition for non-termination (diverges) which must 
hold before execution of a statement in cases where the statement hangs [8]. 
The specification {assumes = (j>, ensures = if, signals = S , diverges = <5} for 
a statement p can be expressed in the notation above as 

{(/)} p {if || S} and [<f A -k5] p [T j| Ae. T] 

(The observation that the derives clause can be coded out in this way is made 
already in [8], and indeed the calculus discussed there forces this coding to be 
used in proofs. Of course, taken literally, this works only classically, but intuition- 
istically, one would at any rate prefer a condition that guarantees termination, 
replacing —>6, over one that is entailed by non-termination.) By consequence, 
also the Hoare calculus of [7] is expressible in our calculus (ignoring, for the time 
being, class constraints on the involved exceptions; given a formal description of 
the class mechanism as described e.g. in [6], such constraints can be expressed 
in the postcondition as carried out in [5]). Explicitly, we can put, e.g., 

{</>} p {exception(S')} := {cf} p {T |j S} and 
[4>\ P [exception^)] := [<f\ p [_L || S], 

thus obtaining conditions stating that, under precondition <f, 
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— if p terminates abnormally with exception e, then the resulting state satisfies 
S e ( partial exception correctness ), and 

— p terminates abnormally with exception e in a state that satisfies S e ( total 
exception correctness), respectively. 

In fact, {(f)} x *— p {i/t \\ S} is equivalent to the conjunction of {(f>} x <— p {?/>} 
and {(f)} p {exception(S')} (while no such simplification holds in general for total 
extended Hoare assertions). 

Example 13. The exceptional Hoare triple {(f)} p {exception(S')} is made ex- 
plicit in T (_ + E) for concrete T as follows: 

— T the state monad: if execution of p from a state s satisfying (f> terminates 
with exception e, then S e holds in the poststate. 

— T the non-deterministic state monad: whenever p possibly terminates excep- 
tionally in state s' with exception e, then S e holds in s' . 

— T the input monad: whenever p throws an exception e after reading a string 
of inputs, e satisfies S e. 

While there is, due to the fact that the calculus of [5, 7] is tailored specifically 
to Java, no precise one-to-one correspondence between the rules listed there and 
our generic rules, the central features of the former do in fact drop out of the 
generic calculus. In particular, the composition rules of [7] can be derived from 
rule (seq) in Figure 3 and its total analogue, and the partial exception while 
rule [5] is the projection of the generic while rule (obtained as a specialization 
of rule (iter) above) to partial exception correctness (i.e. normal correctness is 
just dropped in the conclusion). More interesting is the derivation of the total 
exception while rule: this rule (reformulated in analogy to the total break while 
rule [7]) translates into our calculus as 

[(f) Ab] p [T || T] 

{(f> A b A t = n} p {(f> A b A t < n || T} 

{(f> Ab} p {T || S} 

{(f> A b} while b p {_L || S} 

(with exceptional Hoare triples already coded out) . The premises can be gathered 
into the single total extended Hoare assertion 

[(f) Ab At = n] p [(f> Ab At < n \\ 5] , 

and from this we can indeed draw the required conclusion by means of the generic 
total while rule (while-total) (see above), noting that in the normal postcondi- 
tion, we get the contradiction bA^b. Similarly, the Hoare rules for JML method 
specifications [8] are in direct correspondence with the generic rules of our cal- 
culus. All this is by no means intended to disparage JML (which constitutes a 
much wider effort involving many aspects of a concrete programming language), 
but rather goes to show that the kernel of known specialized Hoare calculi with 
exceptions is covered by our generic mechanism. 
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6 Conclusion and Future Work 

We have generalized existing Hoare calculi for the Java monad [5, 7, 8] to 
a monad-independent Hoare calculus for exception monads, expressed within 
the specification language HasCasl. To this end, we have extended previous 
work [21, 23] on monad-independent calculi by adding postconditions for abrupt 
termination; this was based on an equational characterization of Moggi’s excep- 
tion monad transformer which arose from a rather striking categorical formula- 
tion. 

This extension of the monad-independent Hoare logic is necessary for two 
reasons: 

— the catch operation is not algebraic, but rather acts on top of the monad. 

— exceptions are constants, so that the basic monad independent calculus can- 
not make statements about exceptional post-states 

We argue that both these reasons, in particular the latter, apply uniquely to 
exceptions as a computational feature. By contrast, other computational effects 
are purely algebraic [18], and moreover based on non-constant algebraic op- 
erations. Hence, we expect that the genericity of our approach will allow for 
an easy integration of further monadic computational effects without any sub- 
stantial extensions of the overall formalism as in the case of exceptions. Such 
additional computational effects include in particular input/output [17] and con- 
currency [3, 16]. While the corresponding monads have been designed for use 
with the functional language Haskell, we do not anticipate major obstacles in 
their re-use as extensions of the Java monad [9]. 
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Abstract. We present a logic for reasoning about state transition sys- 
tems (LOTOS behaviours) which allows properties involving repeated 
patterns over actions and data to be expressed. The state transition 
systems are derived from LOTOS behaviours; however, the logic is ap- 
plicable to any similar formalism. The semantics of the logic is given with 
respect to symbolic transition systems, allowing reasoning about data to 
be separated from reasoning about flow of control. Several motivational 
examples are included. 

Keywords: LOTOS, formal verification, temporal logics, infinite state 
systems, symbolic representation. 



1 Introduction 

When describing a system formally it is often useful to be able to do so at 
different levels of abstraction. This enhances our confidence in the correctness 
of our mental model of the system, especially if the different descriptions can be 
related mathematically to each other. An obvious example is the use of modal 
and temporal logics to describe abstract properties of a system which can then be 
validated with respect to a more concrete, implementation focussed, description. 
For example, the use of PROMELA and CTL in the model checker SPIN [1] . 

In previous work we have established a symbolic framework for reasoning 
about Full LOTOS [2] based on Symbolic Transition Systems (STS) [3]. This 
new semantics for LOTOS allows behaviour to be expressed in a more compact, 
elegant fashion than is possible using the standard semantics [2]. In particular, 
this is a way of avoiding the state explosion caused by the use of data in LOTOS. 
A modal logic called FULL has been defined [4] , but although this logic has the 
desirable theoretical property of adequacy with respect to bisimulation [5], it 
lacks the expressiveness required in many applications. 

For example, consider the simple buffer which accepts data at gate in and 
outputs that data at gate out (in pseudo LOTOS, B = in?x:Nat; outlx; B). 
An abstract property of this buffer is ‘‘after an in event, an out event occurs 
Of course, it would be useful to express the repetition of this pattern: “after the 
in action, the out action happens, and then repeat We also want to express 
something about the data involved in the transaction “if we input the value x 
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then what is output is also x, and never anything else'’. Again, it is desirable to 
express this over a number of iterations. 

Another simple example is the communication protocol dealing with lossy 
channels in which an item is sent and resent until an acknowledgement is received 
“ repeatedly send m until ack m” . Here the goal is to repeat a single action an 
indeterminite (but finite) number of times. 

These are simple examples, but they capture the principle that such repeti- 
tions are central to defining the behaviour of many systems, including communi- 
cations protocols, games, hardware systems, operating systems, and telecommu- 
nications. Moreover, it is useful to be able to express these properties in a high 
level, abstract language such as temporal logic. Logics of this nature have been 
defined for LOTOS, most notably in association with the CADP toolset [6-8], 
and used in, for example, verifications of the reconfiguration protocol [9] and the 
IEEE 1394 tree identify protocol [10]. 

Our goal here is to provide a logic which has the expressivity described 
above, and is based on symbolic transition systems, allowing data to be dealt 
with in a more efficient fashion and avoiding some forms of state explosion. 
We present a logic, FULL*, which extends FULL [4], FULL* is designed to be 
expressive: we want the ability to formulate as many useful properties as possible 
since we feel this is more important for the software development process than 
the theoretically desirable adequacy of FULL. The grammar of FULL* draws 
features familiar from traditional modal logics [11,4], and from XTL [12] which 
in turn draws on the language of regular expressions. This paper explores the 
expressivity of the resulting logic via a series of simple examples. In particular, 
key safety, liveness, response and reachability properties are examined. 



2 Reasoning about Infinite State Systems 

Over a number of years we have developed a simple and elegant framework in 
which it is possible to reason about both data and processes (or flow of control) . 
The core of our framework (see Fig. 1) is a symbolic semantics for Full LOTOS [3] 
using Symbolic Transition Systems (STS) [13]. 

Although our main interest is in LOTOS, in fact STS may be used to express 
the semantics of many languages, therefore FULL* is more generally applicable. 
The reader is assumed to be familiar with state transition systems (see, for 
example, Fig. 2). Some very small examples with LOTOS syntax are used, but 
this should not hinder the reader who knows no LOTOS. 

The standard semantics [2] are represented in the leftmost portion of Fig. 1, 
where labelled transition systems give meaning to LOTOS specifications. This 
is the world in which CADP and XTL are based. The righthand portion of the 
Figure represents our contribution: namely, the symbolic semantics for LOTOS, 
an HML-like logic (FULL) [4] and its extension FULL* (described in this pa- 
per), and various flavours of bisimulation [3] (not discussed further here). The 
arrows between the components represent relationships. For example, we have 
proved that the standard, concrete and symbolic bisimulations are all equivalent 
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LOTOS 




Labelled Transition Symbolic Transition Systems 

Systems plus substitution 




standard concrete symbolic modal logic 

bisimulatiorf" 51 bisimulatiorf** bisimulation (FULL) 




FULL* 



Fig. 1. Symbolic Framework for LOTOS 



for closed processes (i.e. those with no free variables), and further, that the same 
equivalence relation is induced by the modal logic FULL. These results are all 
essential to showing the strength and self-consistency of our symbolic frame- 
work, and its consistency with the standard semantics over closed behaviours. 
In other words, we have not simply re-defined the LOTOS language in different 
terms, yielding a different language from that of the standard: we have striven 
to ensure that the two semantics can be used interchangeably, with ours offering 
computational advantages for reasoning about processes. 

Below we reproduce the definitions associated with symbolic transition sys- 
tems and FULL in order to give a basis for the definition of FULL*. 

2.1 Symbolic Transition Systems 

Labelled transition systems are commonly used for specification (e.g. process al- 
gebra semantics, 10 automata). Hennessy and Lin [13] developed a symbolic ver- 
sion of transition systems to combat the problems of infinite breadth introduced 
by transitions over data, and of partial specification introduced through param- 
eterised processes. Related work includes the symbolic simulator of Eertink [14] 
and the NTIF work of Garavel and Lang [15]. Both of these approaches are quite 
different from ours, having as a goal a more efficient implementation of simula- 
tion, equivalence checking, and/or model checking. Also, the NTIF development 
is aimed at interpretation of E-LOTOS behaviours. 

Here we use a version of the Hennessy and Lin symbolic transition systems 
customised to fit the philosophy of communication in LOTOS: multiway synchro- 
nisation, i.e. more than two processes may communicate, and early acquisition 
of values, i.e. binding of values to variables at the point of synchronisation. 

The main features of the STS are that transitions are decorated with a 
Boolean, b, and an action, a. The Boolean expresses under which conditions 
the transition may occur. Actions in LOTOS must be associated with a gate, 
and may additionally offer some data. Therefore we split actions into two sets: 
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SimpleEv and StructEv. An action in SimpleEv consists only of a gate name, g. 
An action in StructEv consists of a gate name g and a data expression d. We 
use a to denote an action in SimpleEv U StructEv. 

The data expression may contain free variables. In this case we refer to it 
as open. Alternatively, it has no free variables and is therefore closed. Similarly, 
LOTOS behaviours, or states in a transition system, may be either open or 
closed. The function fv() can be applied to a behaviour expression to determine 
the free variables of that expression. We do not repeat the definition of fvQ here. 
It can be found in [3]. 

Note there is no syntactic distinction between input and output events since 
this goes against the LOTOS interpretation of events. We can think of data 
offers such as g ! 42 as output events, and g?x : Nat as input events; however, it is 
more accurate to think of these as denoting different sets of values. For “output” 
events the data expression will evaluate to a single value, while for “input” events 
the data expression will be a variable name, potentially instantiated by many 
possible values. In STS the Boolean condition and data expression together 
encapsulate the set of possible values offered at a gate. 

We repeat here the definition given in [3] : 

Definition 1. Symbolic Transition Systems 
An STS is composed of: 

— a non-empty set of states. To each state S, we associate a set of free variables, 
fv(S). This can be computed from the syntactic behaviour associated with S. 

— an initial state, Sq. 

— a set of transitions S — — S', where b is a Boolean expression and a £ 
SimpleEv U StructEv, such that fv(S') C fv(S) U fv(a) and fv(b) C fv(S) U 
fv(a) and | \{fv(a) - fv(S)) < 1. 

That is, any new names in S' must come from the action a, the Boolean condition 
b may refer to variables in S and any new variable introduced in a, and only one 
variable may be introduced by a. The last part of the restriction is an artificial 
imposition by us to make the semantics clearer. In fact, LOTOS syntax allows 
multiple variables to be introduced and this can be modelled using lists. 

Operationally, states are insufficient as a basis for our framework. Consider 
the simple buffer, repeating the actions in?x : Nat ; out ! x. To evaluate this pro- 
cess (e.g. with respect to another process for bisimulation, or with respect to a 
modal formula) a substitution of a value for the variable x is required; however, 
the substitution must change at every iteration. In order to accommodate this, 
the framework for reasoning must be based on terms. 

A term T a is a pair (T, a) where T is a node in the STS being considered 
and a is a substitution, a is a partial function from variables to new variables, 
or to values, i.e. from Var to Var U Val. We require range(a) C fv(T), this 
means parts of the substitution which are no longer relevant are discarded. In 
the definition of both FULL and FULL* the substitutions always map variables 
to values at the time of their first use, therefore for subsequent transitions the 
data item associated with an action is either a value, or a single variable name, 
indicating the introduction of that variable. 
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The notion of transitions between states in a symbolic transition system must 
be transposed to the notion of transitions between terms: 

Definition 2. Transitions Over Terms 

T b a ► T' implies T a ba a > Tf 
T b g£ v T' implies T a ba g£ g T' a 

where fv(E) C fv(T) 

T b gx > T' implies T a fc<T ^ ] T' a [z/x] 

where x £ fv(T) and z £ fv(T a ) 

In all cases, a' = fv(T ') <1 a, that is to say the restriction of a only containing 
elements of }v(T'). 

The third clause above is essential to allow alpha renaming during model check- 
ing when matching variables in the transition system to those in properties. 

In [4] the logic FULL was defined over transitions on terms. Similarly, the 
logic FULL* will be presented over transitions on terms. 

2.2 Paths 

Given that FULL* will include iterative operators we also need to define the 
notion of a path over terms, denoted 7r, as a finite sequence of transitions: 
7 t = ti bl — ► f 2 62 02 ► • • • t n -i — 1 — 1 » t n . Given that STS include free 
variables this means that paths also contain free variables (in the states and in 
the labels a). This is evident in the rules for matching labels of Sect. 3. 

Given 7r as above, operators on paths include: 
first(ir) the first term of a path: firstfir) = t\ 
lastfn) the last term of a path: lastfir) = t n 
initfir) the initial transition on a path: initfn) = t\ — — t 2 
7T • 7T2 If 7T 2 = Si Cl f>1 ► s 2 • • • s m _i s m , and t n = Si, the 

concatenation operator tt ■ tt 2 (or 7 ^ 2 ) is defined as 

f , U Q 1 . +„...+ , h n 1 . 1 f Cl 0! 0.0 C m 1 0 m 1 „ 

L 1 h 2 L n— 1 ^ L n ^2 *m— 1 ^ 

Substitutions over paths are dealt with in the same way as substitutions 
over terms: on taking each transition the substitution is applied if it can be. It 
disappears as soon as it is no longer required. 

2.3 FULL: A Modal Logic for Full LOTOS 

FULL was proposed in [4] in order to express properties of STS and to capture 
the same equivalence as symbolic bisimulation over STS [5]. The form of the logic 
is inspired by HML (Hennessy-Milner Logic [11]), with the addition of quantifiers 
over data. FULL has the following syntax: 

<P ::=b | A <P 2 \ @1 V \ [a]<£ | ( a)<P \ [3a; g\<P 
I [Vx g\@ | (3x g)$ \ (Vx g)T> 

where & is a Boolean expression, a £ SimpleEv, g £ G and x £ Var. 
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Formulae are evaluated over terms (defined above), pattern matching on the 
structure of the logic operators and over the transitions of the system. To illus- 
trate the logic we give the semantics of the different versions of the () operator. 
The complete semantics of FULL is given in [4] . 

t \= (a)& = 3 1', t H a - t' and t' \= $ 

t \= (3x g)<P = 3v s.t. either 3t' , t gt ’ > i! and t' \= <&[ v / x ] 

or 3t t b gz ► t' and b [v / z j = tt and t' [v/z] \= ${ v j x \ 
t |= (Vx g )4> = Vueither 3 t',t — — &-+■ f and t' |= $\ v / x \ 

or 3 t', t ± t' and b [v/z] = tt and t' [v/z] \= $ [v/x] 

where t is a term, z, x € Var and v € Val. 

The features of the logic are that the data and transition quantifiers are 
tightly tied together, with the data quantifier always coming first. This logic 
captures all the discriminatory power of symbolic bisimulation, and with it we 
are able to express certain simple properties capturing ordering of events, and 
manipulation of data. 



3 FULL*: Adding Iteration Operators to FULL 

Clearly, a major drawback of FULL is that properties over sequences of actions 
whose length is unknown cannot be expressed. In turn the essential properties 
of liveness and safety cannot be expressed, yet FULL has a very desirable theo- 
retical property: it captures exactly symbolic bisimulation over STS. 

Here we propose some iteration operators to extend FULL to allow such 
properties to be expressed. The inspiration for the form of the new logic comes 
mainly from the work of Mateescu [12] on XTL, which is in turn influenced by the 
language of regular expressions. The basic innovation of both XTL and FULL* 
is to allow descriptions of properties of paths inside modal operators. A property 
over a path is expressed as a sequence of actions, possibly involving the repetition 
operators “ + ” (1 or more repetitions) and “*” (zero or more repetitions). We 
believe this is a natural and familiar way to express repetition, making this logic 
more accessible to LOTOS practitioners. The novel contribution of our work here 
is adding quantifiers over data and interpreting these operators over symbolic 
transition systems. In FULL* properties are expressed over paths which may 
contain free variables, whereas in XTL properties are interpreted over concrete 
transition systems (with no free variables, and a limited number of values for 
each data type) . 

We also take this opportunity to rationalise the semantics of FULL, intro- 
ducing the -i operator and separating the definitions of quantification over data 
from those of quantification over transitions. In other ways the logic becomes 
more complex. In particular, the effect of the position of quantification has to be 
carefully considered, since it can completely change the meaning of a property. 

Before presenting the formal details of FULL*, we present some examples to 
illustrate the form of the logic. Recall the simple buffer of the Introduction. At 
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the simplest level we wish to write properties with sequences of events, such as 

(in • out)tt 

(i.e. one repetition of the actions in and out). We also wish to repeat patterns 

((in • out)*)tt 

(i.e. zero or more repetitions of the actions in and out). Adding data yields 
((3x in x ■ 3 y(x = y) out y )*) tt 

which we expect to hold. The same property, with (x = y) replaced by (x ^ y) 
would not be expected to hold since it says the buffer outputs a different value 
from that input. 

3.1 FULL* 

Definitions. FULL* Grammar 

<L> ::= b \ <L>i A <P 2 | ( R )<L | 3 x(C)r | -><? 
r ::= 6 1 a a r 2 1 (Q)$ \ ->r 

R ::= a | —<R \ R± A R 2 \ Ri • R 2 \ (R)* \ (R) + I 3x(C)Q 
Q::=a\^Q\Q 1 AQ 2 \Q-R \ (Q)* | (Q) + 

where b and C are Boolean expressions, and a £ SimpleEv U StructEv. 

Given this syntax, V, V and [ ] can all be defined as the duals of A, 3 and ( ). 

The grammar describes modal formulae: L> and F, and patterns (path prop- 
erties) inside modal operators: R and Q. Both r and Q are auxiliary definitions: 
they are identical to <P and R except that they may not include quantification as 
their first operator. This is to make the handling of quantification simpler. By 
imposing this structure on the grammar we ensure that a quantifier is always 
followed directly by an instance of the data being bound. For example, we allow 

3cc(in x)3y(ont y ) tt 



but we do not allow 

3x3y(in a:) (out y ) tt 

Although this is an artificial constraint to make the association of quantifiers and 
variables more straightforward it is not unreasonable since data must always be 
associated with an action, and the expressivity of the logic is not affected. 

Expressions within the logic FULL* are derived by beginning with L>. We 
now explain the meaning of these expressions with respect to a Symbolic Tran- 
sition System, via terms. We split the definition of the semantics into four parts 
corresponding to <L, r, R and Q. In each part the semantics is given inductively 
over the structure of the logical formulae. The definitions are mutually recursive. 
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Definition 4. FULL* Semantics: <P 



t\=b 
t\=<P i A 
t b (R)$ 
t (= 3 x(C)r 

t \= 



b 

t \= L>i A t \= L>2 

37t s.t. first(n) = t A tt \= R A last( n) b ^ 
3v : Val s.t. C[v/x\ = tt A t,v \= r[v/x\ 
t b<£ 



Note in particular that the rule for existential quantification requires satis- 
faction via the rules for r expressions. A value has been chosen and must be 
carried into the next stage of the evaluation so it can be tied to a corresponding 
datum in the transition system. This binding is not possible in the L> rules since 
there may be several transitions (with different actions) from t and only the first 
part of r will determine which particular action is of interest. 

r expressions are evaluated over a pair (term, value), but note that r has 
already had the appropriate substitution applied [v/x\. 

Definition 5. FULL* Semantics: r 

t,v \=b = b 

t, u b A a r 2 = t,v b A a t,v\=r 2 

t, v b {Q)@ = 3 - 7 T s.t. first(n) = f A TT a \= Q A last( tt) g b ^ 

t, v b - ' a = t, v b r 

where cr = [v/ z] if first-data (tt) = z, empty otherwise. 

The auxiliary function first-data (tt) is defined as: 

first-data (n) = if initfir) = t\ — — 2V_ t 2 then z 
if initf n) = t\ - — 22V t 2 then w 

As soon as the path is chosen in the rule for (Q) it is possible to match v 
with a corresponding datum in the transition system, which may be a variable 
(z) or a data value (w). This is done both for the evaluation of Q and for the 
evaluation of the next section of modal formula <F. The latter is important, since 
if there is no substitution here then any matching done in Q is forgotten, and 
the value v is not propagated. This will be illustrated in Sect. 4. If the datum 
returned by first-data (tt) is a value w, then no substitution is applied in the 
(Q)$ rule above. This is because either v = w and the substitution has no effect, 
or v b w and the property will fail when we try to match the first action in 
Q to the first action of tt (see Definition 7). The failure would not happen if a 
substitution [v/w\ had been made. 

We now define formulae over paths described by R. We assume that any 
path chosen in the previous steps is an exact match for the length of R (so we 
don’t have to use init( tt) for example to extract the first part). This is essential. 
Consider the case where a long path is extracted to match only a single action 
R. The rules then ask us to continue evaluating from lastfir). Clearly this misses 
out large chunks of behaviour and is undesirable. 
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Definition 6. FULL* Semantics: R 



7r f = a 
7 r |= -i R 
tt \= R\ A f?2 
TT \= R\ ■ R 2 

*■ b (*)* 

7T |= (i?) + 

7r [= 3a;(<7)Q 



tt = t\ — — t2 A match(a, m) 

7T i? 

7T 1= Rl t\TT \= R 2 

TT = 7T17T2 A 7Tl |= -Rl A 7T 2 |= i?2 
7T = 7Tl • • • 7 T p , p > 0 A VL1 < i < p. TTi |= R 
TT = TT\ ■ ■ ■ 7 Tp, P > 0 A VL1 < i < p. TTi |= R 
3i> s.t. C[v/x] = tt A TT a \= Q[v/x\ 



where p is an integer, and a = \v/z] if first-data (tt) = z, empty otherwise. 

The match function takes two actions, matching the names of the actions, 
and data if there is data associated with the first action, ignoring it otherwise. 
This allows inexact matching of actions. If the logic specifies both gate and data 
then the transition system must match that exactly, but if only a gate is given 
in the logic then any data in the transition system is ignored. 

Lastly we define formulae over Q patterns. Due to substitutions applied above 
a here can only be of the form gv if the formula is well formed (there must be 
data, since the first part of a Q formula has to match a quantifier). 

Definition 7. FULL* Semantics: Q 



tt \= a 

tt b -'<3 
TT \= Ql A Q 2 
TT \= Q ■ R 

TT b (Q)* 

TT b (<9) + 



TT = t X t 2 

TT b Q 

TT b Ql A 7T b Ql 

TT = TTlTT 2 A 7Tl b Q A TT 2 \= R 

TT = TT\ ■ ■ ■ TT p , p > 0 A Vi. 1 < i < P- TTi \= Q 

TT — 7T"l * ’ ’ TT p , p > 0 A Vz.l < i < P- TTi \= Q 



It can be easily demonstrated that all the properties which can be written 
with FULL can be expressed in FULL* just by not considering iterative mech- 
anisms and by restricting the position of quantification. Therefore FULL* has 
at least the expressive power of FULL. More importantly, the addition of iter- 
ative operators give the extra flexibility required to express safety and liveness 
properties, as can be seen in the next section. 



4 Examples of the Use of FULL* 

The semantics presented above are complex, so we present some examples in 
detail to illustrate how the operators might be used, and to give an informal 
explanation of their meaning. We sketch one example unfolding a property using 
the rules above, but the remainder are omitted due to lack of space. 

A Simple Buffer. We return again to the buffer example. Given the transition 
systems of Fig. 2 we can say 



ti (= ((3x in x ■ out ®)*)tt 
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tl ul 




Fig. 2. Buffer processes t and u respectively 



where t\ is the initial state of process t. In fact this is rather weak, since * 
expressions can be satisfied vacuously. 

ti \= ((3x in x • out x) + )tt 

is better, but this property may be satisfied by only a single iteration of the 
pattern. Really we’re trying to express a liveness property here, which can be 
best formulated as 

ti |= -i(->(3x in x- out x) + )tt 

i.e. it is not possible that the buffer does not perform a cycle of in and out 
actions. This property also holds for ui which is not the usual sort of buffer, 
since it sometimes outputs the value 42, regardless of the input, so to more 
accurately describe the buffer something stronger has to be said: 

ti \= [(3x in x • 3 y(x y)out z/) + ]ff 

This formula says that the pattern inside the box operator is not possible (since 
it is followed by ff which cannot be satisfied). This is true for t since the pattern 
says it is possible to output a value different from the one input. Safety properties 
will in general have this form; however, the presence of the box operator means 
the property could be vacuously true, so it is necessary to always combine this 
sort of property with ones expressing that some appropriate behaviour is possible 
(like the liveness property above). Obviously, 

ui [(3* in x • 3 y(x yf y)out y) + ]ff 

since u±, the initial state of process u of Fig. 2, leads to U 2 which can output 42 
at any time. 

To focus on the position of quantifiers, and the substitution of values for 
variables, consider the following 

ti \= [(3x in x)][3y(x = y)out y] tt 

This seems to be a desirable property (similar to that above) but it is mean- 
ingless because the value of x is “forgotten” outside its modal quantifier, so the 
expression x = y cannot be evaluated. So, if properties are to relate different 
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quantified variables, then those variables must be bound inside the same modal 
operator. Conversely, if one variable is used across a number of modal operators 
then it must be bound outside the modal operators. Consider, for example, the 
evaluation of the following property: 

ti |= 3x(in a:) (out x)tt 

First unfold using the rule for 3x(C)T of Definition 4, substituting v for x 
throughout the formula. 

3u : Val s.t. tt A t\,v\= (in u)(out u)tt 

Second, use the rule for (Q)$ of Definition 5, and a carries the mapping infor- 
mation [v/z\ through the transition system. 

3i> : Val s.t. 3-7T first( tt) =t\ A ir a \= in v A last(ir) a |= (out i>)tt 

Otherwise last(n) will not be a suitable model for (out v)tt since z is not bound 
to any value. Success of evaluation relies on choosing the correct path n. 
Finally, consider the property 

3x((in x • out x)*)tt 

This is unsatisfactory because it allows only one value to ever be input (repeat- 
edly). This highlights a feature of the logic: in fact, in repeated patterns the 
quantifiers are most likely to be inside the repetition inside a modal operator, 
allowing new values in each iteration. Also, as was seen above, the scope of a 
quantifier inside an operator is just that operator, so many properties will con- 
sist only of one or two modal operators but with more complex patterns inside. 
This has implications for adequacy, see Sect. 5. 

Communications. Consider the classic communications protocol Alternating 
Bit Protocol (ABP). We do not give the STS here. The idea is that a producer 
and consumer of data are communicating over lossy channels, therefore to ensure 
data sent is received some acknowledgements are set up. The protocol itself uses 
a sender and a receiver, and data is sent with a single bit tag. Each of the sender 
and receiver maintain a record of the tag, or what the tag ought to be in the 
case of the receiver, to help detect errors. For example, if the sender sends (d, b ) 
and the receiver gets {d, b'), where b ' denotes the inverse of b, then the receiver 
knows there has been an error and does not send its acknowledgement. 

From the outside, the ABP behaves just like the buffer: data items go in and 
come out reliably, therefore all of the properties described above can be applied 
if internal behaviour of the protocol is ignored. 

Consider first of all a view of the sending and receiving messages. The proto- 
col behaviour says that any particular message is sent repeatedly until correctly 
received. This reachability property is expressed: 

abp |= (3m(send m) + • receive m)tt 
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From the sender’s point of view, the successful receive is not apparent until an 
acknowledgement with the correct tag arrives, so we might require the following 
property of the sender: 

sender |= (363d (send (d, 6)) + • ack 6)tt 

We take the liberty of using a pair type to represent the data and the tag sent. 
We can be even more explicit about the behaviour at the sender end: 

sender |= (3b3d (send (d,b) ■ (ack err V ack b'))* ■ ack 6)tt 

reflecting the repetition of the pattern that a message is sent, and acknowledge- 
ment received (possibly of the error type, possibly with the wrong tag), until 
a correct acknowledgement is received. Note the use of * here to allow for the 
possibility that errors may not happen at all. 

The sender, once a message is successfully sent, switches to using the tag b'. 
If the above pattern inside the ( ) operator from the 3d is named pjb and the 
property with b and b' swapped named p-not-b then 

sender |= (36((p_6) • {p .not Jo))*) tt 

Now we look more generally at some communication based examples. Con- 
sider that the values sent have a particular sequence, in particular, that the value 
sent increases from each sending to its successor: 

cp 1= [(Va;(send x ■ ->(3 y ( y < a:)send j/)))*]tt 

That is, for all finite paths tt beginning at cp, n can be segmented into tt\ ■ ■ ■ n p 
where 7 t* |= Va;(send x ■ -i(3 y (y < a:)send y)). However, if 7 r is grouped into 
consecutive pairs starting with the first send, then this says nothing about the 
relationship between the data of the second and third sending. If we call the 
property above inc-pairwise then a better formulation may be 

cp \= inc-pairwise A [send] (inc-pairwise) 

effectively staggering the property to consider alternate pairs (2,3), (4,5) and so 
on, as well as pairs (1,2), (3,4), etc. 



Mutual Exclusion. In the classic problem of mutual exclusion there are a 
number of processes executing which have critical and non-critical sections. It 
is required that only one process access its critical section at any one time. A 
master process therefore controls entry and exit from critical sections. A process 
i may enter (inCritical i) or leave (OutCritical i) its critical section. The 
correctness property for mutual exclusion is then 



Vi [InCritical i] Vj(j 7 ^ i) [(^InCritical j)* OutCritical i]tt 
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Assume processes request permission to enter their critical section Ask_ 
Critical i, and then Wait until permission is granted. Processes are guaranteed 
access to their critical section by: 

Vj [(Ask_Critical j ■ (Wait j)* • InCritical j )*] tt 

Note the use of nested occurrences of the * operator. 

As with all [ ] formulae care must be taken to also express properties which 
can do something, to avoid the case that the [ ] formula is satisfied vacuously. 



Summary. Some rules of thumb for expressing properties can be given: 

— Safety properties : express that bad things do not happen, therefore can be 
described in the form [bad_action]ff. 

— Liveness properties : express that good things do happen, therefore can be 
expressed in the form ->(^(good_action) + )tt. 

— Reachability properties: express that eventually it is possible to do a good 
action, ignoring some sequence of other actions which may come first, and 
can be expressed as ((other_pattern)* • good_action)tt. 

— Response properties: are similar to reachability properties. These may also 
use the stronger pattern [(other_pattern)*](good_action)tt to indicate that 
on all paths from the current state the desired action is attainable. 

5 Comparison with FULL 

Clearly, FULL* has more expressive power than FULL. In particular, FULL* 
can distinguish between processes which are symbolically bisimilar [3] . 

Given the three bisimilar STS of Fig. 3, A , B and C, with initial states al, 
bl and cl, the following FULL* formulae distinguish them: 

al |= [Vx send x]tt 
61 [Vx send x]tt 
61 |= [(3x(x < 4) send x]tt 
cl [(3x(x < 4) send x]tt 

The crucial point in the formulation of the properties above is that quan- 
tification over transitions happens first (which may also constrain data), and 
then quantification over data occurs. This gives us the opportunity to choose 
the “wrong” transition. Symbolic bisimulation on the other hand allows us to 
ignore to some extent the way data is distributed across transitions. As long as 
the same set of data is used in total, then we can find a matching transition in 
the other process. In the logic FULL, this translates to ensuring that the data 
quantifier precedes the associated transition quantifier to maintain the link with 
symbolic bisimulation. This is done by tightly associating quantifiers over data 
and those over transitions in the semantics. 

FULL* allows the data quantifier to follow the transition quantifier (in fact, 
quantifiers may occur in any order). The final Buffer example above illustrates 
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al 

tt 

send x 

V 

a2 

tt 

rec x 

\/ 

a3 



bl 




b3 b5 

Fig. 3. Bisimilar processes A, 




tt 



rec x 



V 

c3 




c5 



B and C respectively 



why this is necessary. If repetition patterns are used with data, and the data is 
required to change each time through the pattern, then it has to be possible to 
have the data quantifiers inside the modal operators. Therefore we have traded 
expressivity of the logic against adequacy with symbolic bisimulation. 

6 Conclusion 

We have presented an extension to the FULL logic with iteration operators. 
This allows properties over paths whose length is unknown to be expressed. 
The form of these operators was derived from XTL [12], extended with explicit 
quantifiers over data and interpreted over symbolic transition systems. In FULL* 
fundamental verification properties such as liveness, safety and response can be 
defined, as illustrated in Sect. 4. This is important since the uptake of formal 
methods for description of systems relies on the expressivity and ease of use of 
the language for realistic problems. Another key factor is automated analysis, 
and one of our goals in developing the symbolic framework is to make analysis 
more tractable by reducing the state space of the system. 

Further work will validate this logic using “real-life” examples of LOTOS 
specification using data, aided by a prototype model checking implementation 
in CADP. The symbolic nature of the transitions here is not reflected since 
CADP is built on Binary Coded Graph representation, but the prototype is 
useful for gaining confidence in the logic. A larger example has been completed 
using the benchmark RPC case study [16]. The properties expressed concern the 
ability of the memory to respond appropriately to a call, and are rather similar 
to those given for the communications protocol above. We will carry out further 
case studies to demonstrate the expressivity and useful features of FULL*. 
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Abstract. We are interested in static analysis of programs which use 
shared mutable data structures. We introduce a backward and a forward 
analyses with a separation logic called BI^" . This logic is an extension 
of BI logic [7], to which we add fixpoint connectives and a postponed 
substitution. This allows us to express recursive definitions within the 
logic as well as the axiomatic semantics of while statements. Unlike the 
existing rule-based approach to program proof using separation logic, 
our approach does not have syntactical restrictions on the use of rules. 



1 Introduction 

In this paper we address the problem of doing static analysis of programs [2] 
which use shared mutable data structures. The final goal of our work is to detect 
errors in a program (problems of dereferencing, aliasing, etc.) or to prove that 
a program is correct (with respect to these problems) in an automatic way. 
John Reynolds, Peter O’Hearn and others have developed [7,10] an extension 
of Hoare logic called separation logic (also known as BI logic) that permits 
reasoning about such programs. The classical definition of predicates on abstract 
data structures is extended by introducing a “separating conjunction” , denoted 
*, which asserts that its sub-formulae hold for disjoint parts of the heap, and 
a closely related “separating implication”, denoted — **. This extension permits 
the concise and flexible description of structures with controlled sharing. 

We extend this logic with fixpoint connectives to define recursive properties 
and to express the axiomatic semantics of a while statement. We present for- 
ward and backward analyses (sp (strongest postcondition), wlp (weakest liberal 
precondition) expressed for all statements and all formulae). 



Organization of the paper In Sect. 2 we describe the commands language 
we analyze and in Sect. 3 we present our logic BI^ V . In Sect. 4, we provide a 
backward analysis with BI ^ in terms of “weakest liberal preconditions”. We 
express the wlp for the composition, if — then— else and while commands. 
In Sect. 5, we provide a forward analysis with B I IJV in terms of “strongest 
postconditions” . 
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Background Hoare logic [6] and Dijkstra-style weakest-precondition logics [4] 
are well known. It is also well known that these logics disallow aliasing , that is, 
the logics require that each program variable names a distinct storage location. 
Therefore, it is difficult to reason about programs that manipulate pointers or 
heap storage. 

Through a series of papers [9,7,10], Reynolds and O’Hearn have addressed 
this foundationally difficult issue. Their key insight is that a command executes 
within a region of heap storage: they write 

s,h \= (f> 

to denote that property <j> holds true within heap subregion h and local- variable 
stack s. One could also say that a formula describes some properties of the 
memories it represents. For example, <f> might be: 
emp means that the heap is empty 

E i— > a,b means that there is exactly one cell in the heap, the one 
containing the values of a and b and that E points to it. 

E c — ► a, b is the same except that the heap can contain additional 
cells 

With the assistance of a new connective, the “separating conjunction”, de- 
noted *, Reynolds and O’Hearn write 



s, h i ■ h 2 \= 4> i*fa 



to assert that both cj > i and <f> 2 hold but use disjoint heap subregions to justify 
their truth - there is no aliasing between the variables mentioned in fa and fa. 
For example, consider the two cases below. 



If s = 



s,n |= 
If s = 



x — ■> l\ 
y -» h 


, h = 


li > (3, 4) 
>-(1,2). 


(x 3, 4) but s 


h (x 3 



, h = 



then s, /i|=(ih 3, 4) * (y i— > 1 , 2) or also 

4 ). 

(3,4)] then s, h \= (x i— > 3, 4) A (y i— > 3,4) but 



x — > l\ 

y->h 

s, h ¥= (x 3, 4) * (i/ m 3, 4). 

Adjoint to the separating conjunction is a “separating implication” : 



S, h\=fa~* fa 



asserts, “if heap region h is augmented by h' such that s, h' \= (j>\ , then s, h-h' |= 

x — > li 



</> 2 ”. For example: if s = 



y 



h 



, h = [l i — > (3,4)] then s, h |= (y h-> 1,2) 



*((x 3,4 )*(|/h 1,2)). 

Istiaq and O’Hearn [7] showed how to add the separating connectives to a 
classical logic, producing a bunched implication logic ( BI or separation logic) 
in which Hoare-logic-style reasoning can be conducted on while-programs that 
manipulate temporary-variable stacks and heaps. 

A Hoare triple, {<f>i}C{(/) 2 }, uses assertions fa, written in separation logic; 
the semantics of the triple is stated with respect to a stack-heap storage model. 
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Finally, there is an additional inference rule, the frame rule, which formalizes 
compositional reasoning based on disjoint heap regions: 

{f > i * <t>'}c{(f> 2 * 4>'} 

where <//’ s variables are not modified by C. 

The reader interested in the set-of-inference-rules approach for separation 
logic is invited to read [7], and [11] for details on the frame rule. The rules could 
also be found in a survey on separation logics [10]. We do not present the set of 
rules in this paper. 



Our contribution Istiaq and O’Hearn’s efforts were impressive but incomplete: 
the weakest-precondition and strongest postcondition semantics for their while- 
language were absent, because these require recursively defined assertions, which 
were not in their reach. 

The primary accomplishment of this paper is to add least- and greatest-fixed- 
point operators to separation logic, so that pre- and post-condition semantics 
for the while-language can be wholly expressed within the logic. As a pleasant 
consequence, it becomes possible to formalize recursively defined properties on 
inductively (and co-inductively) defined data structures, e.g., 

nonCircularList(a:) = 

pX v . {x = nil) V 3aq, ;E 2 .(isval(;ri) A (x i— > x\, X 2 * X v [x 2 /x ])) 

asserts that a: is a linear, non-circular list (isval(;ri) insures that x\ is a value, 
this predicate is defined later). 

The addition of the recursion operators comes with a price: the usual defi- 
nition of syntactic substitution and the classic substitution laws become more 
complex; the reasons are related both to the semantics of stack- and heap-storage 
as well as the inclusion of the recursion operators; details are given later in the 
paper. 

2 Commands and Basic Domains 

We consider a simple “while” -language with Lisp-like expressions for accessing 
and creating cons cells. 



2.1 Command Syntax 

The commands we consider are as follows. 

C ::= x := E \ x := E.i \ E.i := E' \ x := consul, E 2 ) | dispose)!?) 

| Ci;C 2 | if E then Ci else C 2 | skip | while E do C\ 
i ::= 1 | 2 

E ::= a: | 42 | nil | True \ False \ E\ op E 2 
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An expression can denote an integer, an atom, or a cons cell. Here a; is a variable 
in Var and op is an operator in (Val xVal) —> Val like + : ( Int x Int) — > Int , 
Or : ( Bool x Bool ) — ► Bool (about Var and Val see Sect. 2.2). 

The second and third assignment statements read and update the heap, re- 
spectively. The fourth creates a new cons cell in the heap, and places a pointer 
to it in x. 

Notice that in our language we do not handle two dereferencings in a simple 
statement (no x.i.j , no x.i := y.j ), this restriction is just for simplicity and does 
not limit the expressivity of the language (it will just require the addition of 
intermediate variables). 

2.2 Semantic Domains 

Val = Int U Bool U Atoms U Loc 
S = Var — 1 fin Val 
H = Loc fin Val x Val 

Here, Loc = i , Z 2 , - - - } is an infinite set of locations, Var = {x,y,...} is an 

infinite set of variables, Atoms = {nil, a , ...} is a set of atoms, and fin is for 
finite partial functions. We call an element s £ S a stack, and h £ H a heap. We 
also sometimes call an element (s, h) £ S X H a state or a memory. 

We use dom(h) to denote the domain of definition of a heap h £ H, and 
dom(s) to denote the domain of a stack s £ S. 

An expression is interpreted as a heap- independent value: |-E]s £ Val. 

For example, [x]s = s(x), [42] s = 42, [truejs = true , \E\ + E 2 \s = 

[i5i]s+[i5 2 ]a 

2.3 Small-Step Semantics 

The semantics of the statements are given in small-step semantics defined by 
the relation on configurations. The configurations include triples C, s, h and 
terminal configurations s, h for s £ S and h £ H. 

In the following rules, we use r for elements of Val x Val , 7 r*r with i £ { 1,2} 
for the first or second projection, and (r\i — > v) for the pair like r except that 
the *’ th component is replaced with v, [s | x — > u] for the stack like s except that 
it maps x to v, ( h - l) for ft Idom(k)U1( . 

jEjs = v jEjs = l h(l) = r 

x := E,s,h [s|x —* v\,h x := E.i, s,h [s|x — > 7 Tjr], h 

[A]s = l h(l) = r [il'ls = v' l £ dom{h) [A]s = l 

E.i= E r , s,h s, [ h\l —> ( r\i — > i> 7 )] dispose)!?), s,h s, C h-l ) 

l £ Loc l dom(h) [i?i]s = iq, [^Js = v 2 
x := cons(i?i, E 2 ), s,h •w [s|x — > /] , [h\l — > (v\, 7 ) 2 )] 

Ci,s,h C', s', h' Ci,s,h s', h! 



C\;C 2 ,s,h C'\C 2 ,s',h' C%$C 2 ,s,h C 2 ,s',h' skip, s, h s, h 
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[-Ejs = True [E]s = False 

if E then C\ else C2, s, h -w C\, s , h if E then C\ else C2, s,h -w C2, s, h 

[£]s = False [E]s = True 

while E do C, s, h s, h while E do C, s, h C; while E do C, s , h 

The location l in the cons case is not specified uniquely, so a new location is 
chosen non-deterministically. 

Let the set of error configurations be: 17 = {C, s, h \ $K. C,s,h -w K }• 

We say that: 

“C, s, h is safe” if and only if MK. ( C , s, h ~>* K => K §£ 17) 

“(7, s,h is stuck” if and only if C, s, h € 17 

For instance, an error state can be reached by an attempt to dereference nil 
or an integer. Note also that the semantics allows dangling references, as in stack 
[x — *■ l] with empty heap []. 

The definition of safety is formulated with partial correctness in mind: with 
loops, C, s, h could fail to converge to a terminal configuration but not get stuck. 



3 BI v" 

In this section, we present the logic BI^ V . It is designed to describe properties 
of the memory. Typically, for analysis it will be used in Hoare triples of the form 
{P}C{Q} with P and Q formulae of the logic and C a command. 

We present in Sect. 3.1 the syntax of the logic and in Sect. 3.2 its formal 
semantics. In Sect. 3.3, we give the definition of a true triple {P}C{Q}. At 
the end, in Sect. 3.4, we discuss the additions to separation logic (fixpoints and 
postponed substitution) . 



3.1 Syntax of Formulae 



E = E' 


Equality 


| E 1— > E \ , E2 


Points to 


false 


Falsity 


\ P => Q 


Classical Imp. 


3a;. P 


Existential Quant. 


emp 


Empty Heap 


P *Q 


Spatial Conj. 


\P^Q 


Spatial Imp. 


x v 


Formula Variable 


P[E/x] 


Postponed Substitution 


vX v .P 


Greatest Fixpoint 


pX v .P 


Least Fixpoint 



We have an infinite set of variables, Formula-Variables, used for the vari- 
ables bounded by p and v and disjoint from the set Var. They range over sets 
of states, the others ( x,y ,...) are variables which range over values. For the sake 
of clarity, uppercase variables with the subscript v are used to define recursive 
formulae. We use the term “closed” for the usual notion of closure of variables 
in Var (closed by 3 or V) and the term “u-closed” for closure of variables in 
Formula-Variables (u-closed by p or v). 

Our additions to Reynolds and O’Hearn’s separation logic are the fixed-point 
operators pX v . P and vX v . P and the substitution construction P[E/x\. 
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We can define various other connectives as usual, rather than taking them 
as primitives: 

-iP = P =$■ false true = -i(false) 

P V Q = (~'P) => Q PAQ = n(nP V nQ) 

Mx.P = -i(3a ;. nP) E a, b = true * {E i— > a, b) 

x = E.i = 3xi, X2 ■ (E > xi, X2) A (x = Xi) 

The set FV(P) of free variables of a formula is defined as usual. The set 
Var(P) of variables of a formula is defined as usual with Var(P[E/x}) = 
Var(P) U Var(E) U {2}. 

3.2 Semantics of Formulae 

We use the following notation in formulating the semantics: 

— h\h! indicates that the domains of heaps h and h' are disjoint; 

— h ■ h! denotes the union of disjoint heaps (i.e., the union of functions with 
disjoint domains). 

We express the semantics of the formulae in an environment p mapping 
formula variables to set of states: p : Formula-V ariables ^V(S x H). The 
semantics of a formula in an environment p is the set of states which satisfy it, 
and is expressed by: F p : BI ^ V(S x H) 

We call y(P) the semantics of a formula P in an empty environment j(P) = 
r$(P). We also define a forcing relation of the form: 

s, h 1= P if and only if s, h £ y(P) 

and an equivalence: P = Q if and only if \/p.r p (P) = r p (Q). We write T for 
SxH. 



r p (E = e') 


= {s,h\ IE\8 = [E']s} 


r p (E 1 — ► Ei, E 2 ) 


= {s, h j dom(h) = {[Pjs} 
and = (lEijs, {E 2 ]s)} 


r p (false) 


= 0 


r P (P =► Q) 


= (T\r p (P))ur p (Q) 


r p (3x.p) 


= {s, h | 3v £ Val.[s\x —* v],h € r p (P)} 


r p (emp) 


= {s,h\h= []} 


r P (P * Q) 


= {s, h | 3Hq, hi ho$hi, h = ho ■ hi 
s, h 0 G r p (P) and s, hi G r p (Q)j 


r P (P -*Q) 


= {s, h | Mh' , if /ijj/i' and s, h' G r p (P) then 
s,h- h! G r p (Q)} 


r p (x v ) 


= p{X v ) , if X v G dom(p) 


r p (px v . p) 


= lipfxx. r [plXv ^ x] (P) 


r p {isX v . p ) 


= gfp 0 -AX r MXv ^ x] (P) 


r p {P\E/x\) 


= {s,h\ s[x [P]s], h G r p {P)} 



In both cases p, and is, the X in AX is a fresh variable over sets of elements 
in SxH which does not already occur in p. 
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Notice that r p is only a partial function. In definitions above, lfp ^<j> 
is the least fixpoint (greatest fixpoint) of ^ on the poset {V(S x if),C), if it 
exists. Otherwise, r p (pX v .P) (r p {yX v .P)) is not defined. For example, this is 
the case for pX v . (X v => false). 

We do not give a syntactical criterion for formulae with defined semantics 
(like parity of negation under a fixpoint, etc.), they are the usual ones knowing 
that in terms of monotonicity, — >* acts like =>, * acts like A, and [ / ] do not 
interfere. 

3.3 Interpretation of Triples 

Hoare triples are of the form {P}C{Q}, where P and Q are assertions in BI ^ 
and C is a command. The interpretation adopted ensures that well-specified 
commands do not get stuck (by this, it differs from the usual interpretation of 
Hoare triples). 

{P}C{Q} is a true triple iff Vs, h if s, h \= P and FV(Q) C dom(s) then 

- C,s,h is safe 

- if C, s, h ~^>* s', h’ then s', h’ f= Q 

This is a partial correctness interpretation; with looping, it does not guarantee 
termination. This is the reason of expressing “weakest liberal preconditions” 
for our backward analysis and not “weakest preconditions” . However, the safety 
requirement rules out certain runtime errors and, as a result, we do not have that 
{true}C'{true} holds for all commands. For example, {true}x := nil;x.l := 
3{true} fails. 

3.4 Adding of Fixpoints and Postponed Substitution 

In this section, we discuss our motivations for those additions. We show that the 
postponed substitution connective [ / ] is not the classical substitution { / } and 
that the usual variable renaming theorem does not hold for { / }. 

First motivation Our first motivation for adding fixed-point operators to sep- 
aration logic came from the habit of the separation logic community to define 
informally recursive formulae and to use them in proofs of correctness. 

Since we have added fixed-point operators to the logic, we can formally and 
correctly express, for example, that a; is a non-cyclic finite list as 

nclist(x) = fiX v . {x = nil) V 3x±, X2.(isval(xi) A (x i— ► Xi, * X v [x2/x\)) 

and that x is non-cyclic finite or infinite list 

nclist(x) = vX v . ( x = nil) V 3xi, X 2 .(isval(xi) A (x i— > xi,X 2 * X v [x2/ x})) 

where isval(x) = (x = true) V (a; = false) V (3 n.n = x + 1) 

In earlier papers [8], Reynolds and O’Hearn use the definition, 

nclist(a:) = (x = nil) V 3xi,X2.(isval(xi) A (x e- > X\,X 2 * nclist(x 2 ))) 

which is not within the syntax of separation logic. 
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Second motivation The second motivation was the formulations of the wlp 
({ ? }C{P}) and sp ({P}C{ ? }) in the case of while commands, which was 
not possible earlier. This problem is nontrivial: For separation logic without 
fixed-points, we might express sp as 

sp(P, while E do C) = (lfp '7aise AX.sp(XA.E = true, C)VP) A (i? = false) 

with lfp £ a i se XX.F(X) defined, if it exists, as a formula P which satisfies: 

- P = F(P) 

— for any formula Q, ( Q = F{Q) implies P \= Q ) 

with P = Q if and only if P \= Q and Q \= P. 

But this implies that during the computation of the sp, each time a while 
loop would occur, we must find a formula in existing separation logic that was 
provably the Rxpoint, so that we could continue the computation of the sp. In 
an other sense, this “work” could be seen as the “work” of finding the strongest 
loop invariant in the application of the usual rule for while loop. 

Our addition of fixpoints (and the related postponed substitution) allows us 
to express the sp directly within the logic: sp(P, while E do C) = (pX v .sp(X v A 
E = true, Ci) V P) A (E = false). 

Although the definitions of the wlp and sp for the while loop are simple and 
elegant, the “work” of finding loop invariants is not skipped, however it is now 
postponed for when we have a specific proof to undertake. For example, we are 
working on translations of formulae into some other domains, and we have to 
find an approximation of the translation of fixpoints which is precise and not 
too expensive to compute. The advantage here is that this work of building the 
translation is done once and for all, then the analysis can be fully automated 
while the methodology of a proof system and finding loop invariant implies hand 
work. 



[ / ] is not { / } In this paper, we use the notation P{E/x} for capture- 
avoiding syntactical substitution (that is, the usual substitution of variables). 
Recall that [ / ] is a connective of the logic (called postponed substitution) and 
is not equivalent to { / }. 

The distinction between [ / ] and { / } can be viewed in this example: 

(trueja: := j/{true} is false 

(the command will be stuck from a state that has no value in its stack for y) 

which implies that the axiom for assignment, {P{y /x}}x := y{P}, is unsound. 

In other versions of separation logic [10], {P{y/x}}x := y{P} was correct, 
since the definition of a true triple requires FV (C, Q) C dom(s) and not merely 
FV ( Q ) C dom(s) like here and also because there was no recursion. We believe 
that our definition is better since it does not require variables of the program 
to have a default value in the stack and it checks whether a variable has been 
assigned before we try to access its value. 
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Unfolding Notice that as usual, we have: 
yX v .P = P{yX v .P/X v } 
uX v .P = P{vX v .P/X v ) 



{/}: no variable renaming theorem 3y.P ^ 3 z.P{z/y} with 2: ^ V 'ar(P) 
( when y ^ z) 

Here are two counterexamples to the equivalence: 

Example 1: 7 (uX v .y = 3 A 3 y.(X v A y = 5)) ^ 7 (vX v .y = 3 A 3 z.(X v A 2 = 5)) 
because (*) let A = 7 (a) = 7 (vX v .y = 3 A 3 y.(X v Ay = 5)) = 0 
and (**) let B = 7 [vX v .y = 3 A 32. (X„ A 2 = 5)) = 7(2/ = 3) 

Explanation: 

(*) the “y = 3 A” part says that all the states in A should satisfy y = 3, 
the “3y.X v A y = 5” part says that for all states in A, we can put a value to y 
such that the state satisfies y = 5 and is still in A. which brings a contradiction 
with the previous condition, so we have A = 0. 

(**) the “2/ = 3 A” part says that all the states in B should satisfy y = 3, 
the “3 z.X v A 2 = 5” part says that for all states in B , we can put a value to 

2 such that the states satisfies 2 = 5 and is still in B which is possible for any 
state of B, so we have B = 7(2/ = 3). 

Example 1 shows that variable renaming has a special behavior when applied 
to a formula which is not n-closed. 

Example 2: 'y(3y.i'X v .y = 3 A3y.(X v Ay = 5)) ^ 7(3 z.vX v .z = 2>A3y.{X v Ay = 
5)) 

because (***) let C = 7(c) = 'y(3y.uX v .y = 3 A 3y.(X v A y = 5)) = 0 
and (****) let D = 7 (d) = 7(3 z.vX v .z = 3 A 3y.{X v A y = 5)) = S x H 
Explanation: 

(***) c=3y.a, 

the result comes directly from the explanation of the case of A 

(****) if we take the explanation of B , we get that E = 7(e) = 7 {vX v .z = 

3 A 3y.{X v A y = 5)) = 7(2 = 3), then since d = 3 z.e we have that the states in 
D are such that we can find a value to give to 2 such that 2 = 5, this is trivially 
true and then any state is in D, so we have D = S x H . 

Example 2 shows that variable renaming has a special behavior in case of y 
if the variable renamed is bounded inside the y . 



Full substitution The previous Example 2 leads to the definition of a new 
substitution. 

Let {[ / ]} be a full syntactical variable substitution: P{[z/y]} is P in which all 
y are replaced by 2 wherever they occur, for example: 

(3y.P){[z/y)} ± 3z.(P{[z/y}}), (p[E/x]){[z/y}} 4 (P{[z/y]})[E{z/y}/x{z/y}} 




484 



Elodie-Jane Sims 



The variable renaming theorem for BI^ V If P is /.--closed and z $ Var(P), 
y FV(P ) then P = P{[z/y}} (in particular 3y.P = 3z.{P{[z/y}})). 



Equivalences on [ / ] 

- If P is u-closed and if X\ Var(E ) and x\ ^ x 2 - then: 

(3x 1 .P)[E/x 2 } = 3x 1 .(P[E/x 2 \). 

- (3x.P)[E/x\ = (3x.P) A is(E). 

- (A V C)[E/x] = [A[E/x] | V (C[E/x]) 

- If y £ Var(P) then 

(yX : v .P)[y/x] = (nX v .P{[y/x]}) A is(y) 

{i'.X,..P) y ./'| = (i/.Y„.P{[y/x]}) A :is(z/) 

One would want this for E instead of y but this is not possible in this way 
since (P[E' /x]){[E /x]} is not defined because P[E’ / E] is not defined (what 
has to be substituted must be a variable). This is the point of the existence 
of [ / ] as a connective. 

To understand the last rule, we can come back to the program point of view 
seeing fixpoints as while loops and [ / ] as assignments, the precondition for 
x := w; while x = y do x := x + 1 is the same as the one for while w = 
y do w := w + 1 (if you have seen Sect. 4 this would be {vX v ,(x ^ y) V {{x = 
y) AX v [x+l/x]))[w/x] = is(w)A(i'X v .(w ^ y)V((w = y) AX ( [»+ 1/tft])))- 



Example of unfolding nclist42 

Let nclist42(.r) = yX v .(x = nil) V 3xo-({x i— 42,a’2) * X v [x 2 /x\) with 
Xo ^ x. 

One would expect there X v [x 2 /x\ to be equivalent to nclist42(a: 2 ). 

Remark that nclist42(a’2) = yX v .(x 2 — nil)V3a:3.((a’ 2 42,X3)*X v [xz/ x 2 \) 

with xs ^ x 2 . 

Let’s prove that X v [x 2 /x\ is equivalent to nclist42(.X2). 

nclist42(ar) = fiX v .(x = nil) V 3x 2 .{(x i-» 42, x 2 ) * X v [x 2 /x}) 

( unfolding ) = (x = nil) V 3a: 2 .((.r 42, x 2 )* 

(( yX v .(x = nil) V 3a: 2 .((a: 42, * 2 ) * X v \g&/x]))[x 2 /x])) 

(variable renaming for BP iy ) = (x = nil) V 3a/2-((a: ^ 42,. v 2 )* 

((/r X v .(x = nil) V lr :i .l(x ec 42, x 3 ) * X v [x^/x]))[x 2 /x])). 

(simplification [ / ] case /i) = (a: = nil) V 3.12. ((a; ^ 42, a- 2 )* 

(fjX v .(x 2 = nil) V 3a’3.((x 2 i-> 42, x 3 ) * X v [x 3 /x 2 ]))) 
4 (a- = nil) V 3x 2 .((x 42, a’ 2 ) * nclist42(x 2 )) 



So we have nclist42(a: 2 ) = (nclist42(a:))[a: 2 /a'] as expected. 
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Why BI + fi -j- v ^ B I ? Or, why do we need to add [ / ] to the syntax ? 

Informally said, one can see the fixpoints as a while loop and [ / ] as an 
assignment, then if we have a while loop followed by an assignment, we cannot 
include the assignment within the loop. So, if an analysis postponed the compu- 
tation of while loop/fixpoints, then it also has to postpone the computation of 
assignment/ [ / ]. 

This need of [ / ] is not surprising. In [3] , de Bakker proved that for his simple 
logic with only fixpoints, there was no sp for the while loop statements. 

We define is(E) as a shortcut for E = E, which is just a formula insuring 
that E has a value in the current memory. 

For P without any p,v,X v in it. we have P[E'/x] = P{E’/x} A is(E'). But for 
BP LV without the connective [ /], there is no formula in the logic equivalent to 
P[E' /x\, which means that [ / ] has to be in the logic syntax. 

For example, (3y.P)[E/x] ^ 3 y.(P[E/x\) when j / i but y G Var(E) but 
the renaming theorem: 3 y.P = 3z.P{z/y} with z Var(P) does not hold, so 
the attempt to find an equivalent formula for (3y .P)[E / x] will fail. 

4 Backward Analysis 

We now define the weakest liberal precondition ( wlp ) semantics of the while-loop 
language with pointers. 

If we can establish {P}C{true} then w r e will know that execution of C is 
safe in any state satisfying P. So for our backward analysis, we express wlp such 
that 

{wlp(P,C)}C{P} is true 

Most of the clauses are from Istiaq and O’Hearn [7], but our definition for 
while E do C is new and crucial. 



wlp(P, 


x := E) 


= P[E/x ] 


wlp(P, 


x := E.i) 


= 3x\ 3x-2-(P[xi/x] A (E .r 1 ../- 2 n 
with X i $ FV{E,P) 


iulp(P, 


E. 1 := E') 


= h.1'1 :./‘o - ( /'• 1 — > Xi-Xo) * ((£ 1 ^ E',x 2 ) — *P) 
with Xi #FV(E,E',P) 


wlp(P, 


E. 2 := /•.') 


= 3xi3x-2-(E t— y x 1 , x 2 ) * ((E x\.E') —*P) 

with Xi 0 FV(E,E',P) 


wlp(P, 


x := consjiy. , £ 2 )) 


= VP./P 1 — f E \ , Eo) —*P[x'/ a:] 
with x' FV (Ei, Eo.P) 


wlp(P, 


dispose(P)) 


= P * (3a3b.(E a, b)) 
with a, b 0 FV(E) 


wlp(P, 


Cp,C 2 ) 


= Wlp(wlp(P , C 2 ); Cl ) 


wlp(P, if 


E then C 1 else 


C 2 ) = 




(E- 


= true A wlp(P, C\)) V (E — false A wlp(P, Co)) 


wlp(P , 


skip) 


= P 


wlp(P , 


while E do Ci) 


= vX V .((E = true A wlp(X v , Ci)) 
V(£ = false A P)) 



with X t ,not in P 
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4.1 Proof of the Backward Analysis 



Definition of wlp 0 To prove that our definition indeed defines the wlp , we will 
formally relate it to the inverse state-transition function defined by the opera- 
tional semantics in the domain V(S x H): 

wlp 0 (A, C) = {s, h | C , s, h is safe A(if C, s, h s', h’ then s', h' G A} 



We can instantiate the definition of a true triple as: 

BI 

{ wlp{P , C)}C{P} true 
if and only if 

7 (wlp(P,C)) \cwlvh(P)C ) 

n{s,h | FV(P) C dom(s)} ) ~ M7 1 j 

op C 



wlp 



Wlpo 



op 



To prove that our analysis is correct, we express wlp 0 for each command, 
and prove by induction on the syntax of C that for each C and P, we have 
j(wlp(P, C)) C wlp 0 (^(P),C). 

To prove that those preconditions are the weakest we have established that 



1 {wlp{P,C)) = wl Po { 1 {P),C) 



5 Forward Analysis 

In the previous section, we have defined wlp for each C and P such that 
{wlp(P, C)}C{P} is true. 

The strongest postcondition semantics sp(P,C ) is not always defined, i.e., 
we can find C and P such that there exists no Q that makes {P}C{Q} true. 
This is due to the fact that a true triple requires C to be executable from all 
states satisfying P (and also such that FV(Q) C dom(s)) which is obviously 
not the case for some C and P. (For example, (truejx = nil\y — x.l; {?} has 
no solution, since all states satisfy P but the command can never be executed - 
nil.l is not defined). 

We therefore have to split the analysis into two steps. The first step checks 
whether C is executable from all states satisfying P or not. The second step gives 
sp(P,C) that makes the triple {P}C{sp(P, C)} true if C is executable from all 
states satisfying P. 



5.1 Step 1: wlp(tru.e, C) 

C is executable from any state satisfying P if and only if P \= wlp(true, C ). 

So for the first step we express the wlp{ true, C) formulae. These are just the 
formulae given in Sect. 4, instantiated for P = true. 
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5.2 Step 2: sp(P, C ) in Case P (= wlp{ true, C) 

The postcondition formulae are: 

sp(P, x := E ) = 3x'. P[x'/x] A x = E{x’/x} 

with x' FV(E, P) 

sp(P, x := E.i) = 3x3 P[x' /x\ Ai = i Ar})./' 

with a:' FV(E, P ) 

sp(P, P.l := F'f = 3xi3x 2 .(P E'f x 2 ) * ((P ► Xi, x 2 ) — *P) 

with x, FV(E,E',P) 

sp(P, E.2:=E’) = 3xt3x2-{E <— > xi, E') * {{E xi,x 2 ) — *P) 

with x* £ FV(E, E 1 , P) 

sp(P , x := cons(£i, P 2 )) = 3x'.(P[x , /x] * (x Pi{x'/x}, p 2 {x'/x})) 

with x' ^ FV(Ei,E 2 ,P) 
sp(P, dispose(F)) = 3 xi,x 2 . ((P i— >■ xi,x 2 ) — *P) 

with xi,x 2 ^ FV{E, P) 

sp(P, Ci;C 2 ) = sp(sp(P, Ci),C 2 ) 

sp(P , if P then Ci else C 2 ) = sp(P A E = true.Cx) 

Vsp(P A E = false, C 2 ) 
sp(P, skip) = P 

sp(P, while E do Ci) 7 = (pX v .sp(X v A E = true, Ci) V P) 

A (E = false) 
with X[,not in P 

5.3 If P {A wlp(tTue , C) 

If P wlp(tTue,C), we conclude that C cannot be executable from all states 
satisfying P, but for those states from which C is executable, the final states 
satisfy sp{P A udp(true, C), C). 



5.4 Proof of the Forward Analysis 

We want to prove that: If P (= wlp( true, C) then {P}C{sp(P, C)} true. 

Definition of sp Q We define the strongest postcondition in the operational do- 
main: 

s Po (A, C) = {s', h! | 3s, h e A. C, s, h s', /?.'} 

Now, we can instantiate the definition of a true triple as: 

{P}C{Q} true if and only if P |= tpp(true, C) A sp 0 {j(P), C ) C 7 (Q) 

To prove that our analysis is correct, we express sp 0 for each command, and 
prove by induction on the syntax of C that for each C , and P, we have 
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>BI 



If P f= wlp( true, C) 

then sp 0 (7(P), C) C 7(sp(P, C)) 



7 



7 



op C op 

But since sp 0 is defined such that it only collects the final states of successful 
computations, we must only prove that for each command C: 
s Po ( 7 (P),C)C 1 (sp(P,C)) 

We have proved that our postconditions are the strongest by proving that: 



sp 0 ( 1 (P),C)= 1 (sp(P,C)) 



5.5 Remark on Using the Result of Our Analyses 

Our analyses always give the most precise and correct result. However, most 
of the time the result is not suited for humans. Hence, a theorem prover may 
be necessary. For example, the user will express some initial condition before 
running a program, the analysis will give the safe initial condition (wlp( true, C)) 
and the user will have to use a theorem prover to check whether the initial 
condition implies the safety initial condition (or do it by hand). In the other 
way, the user can express some postcondition and check if the postcondition 
provided by the analysis implies the postcondition that was expected. 

Of course no theorem prover can always answer those questions since the 
validity of a formula is undecidable [ 1 ], The satisfiability of the /i and v may also 
be a problem in practice. 

Even if the analyses here are not of direct use to automatically check pro- 
grams, they can still be useful. We plan to use the logic as an interface language 
for other point-to analyses . For this we would translate the domain of those 
analyses into the logic (and conversely) . Furthemore, we would also like to prove 
the correctness of some of those analyses, and then the expressions of our wlp 
and sp could be helpful. Those wlp and sp could also be useful as an interme- 
diate step for an analysis which would consist in first going from a program to 
a formula of BI 1 "' , then to another more abstract domain. Then the usual chal- 
lenge of finding a loop invariant would result in finding an approximation for 
the translation of p, and v in this last domain. This last approach is our current 
and future work. 

6 Conclusion 

Checking programs dealing with pointers is an old challenge but still alive. There 
are many pointer analyses but none of them would be elected as the one which 
is precise enough, efficient and entirely formally proved. We do not get into the 
challenge in this paper but we think separation logics could become a good help 
to work towards this aim. 
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We have proposed an extension of separation logic, with fixpoint connectives 
and postponed substitution. First, this allows us to express formulae of recursive 
definitions within the logic. Secondly, it allows us to express the sp and wlp in 
the case of while statements (in our knowledge, there is no forward analysis 
using separation logic in the literature) . We expressed the sp and wlp operators 
for any statements without any syntactical restrictions on the formulae provided 
as pre- or post-conditions. This leads to automatic analyses which is a quite 
different approach from the set of rules analyses which usually include a big part 
of human work for each program. 

Towards real program analyses, the remaining difficulty is to interpret the 
results of our analyses. 

This could be solved by finding some human understandable formulae that 
are equivalent to the one provided by our analyses, or proving that the result im- 
plies (or is implied by) another formula. This would need use of theorem provers, 
or approximation technics (our analyses are the most precise). (D. Galmiche and 
D. Mery are doing some work on building a theorem prover [5] but not for our 
syntax of separation logic. Indeed Calcagno and others proved in [1] that deciding 
the validity of an assertion in separation logic is not decidable.). 

Another approach, which is an ongoing work, is to translate the formulae into 
some other (more specific or approximating) domains and reversely. This could 
lead to a two step analysis: first step translate the program into formulae with 
the wlp or sp, second step translate the formulae into the chosen domain. This 
approach is parallel to the use of this logic as an interface language between other 
analyses (this is motivated by the simplicity for human to write useful primitives 
with this logic, for example to point to a non-cyclic list). As an example, we have 
illustrated our approach for a partition analysis. 
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Abstract. We present a calculus for the verification of sequential Java 
programs. It supports all Java language constructs and has additional 
support for Java Card. The calculus is formally proved correct with re- 
spect to a natural semantics. It is implemented in the KIV system and 
used for smart card applications. 



1 Introduction 

The Java language has received a formal treatment for a couple of years now, see 
e.g. [1] [2] [9] [11] [15] [24]. While issues like type safety have been solved [22], most 
people perceive that the problem of proving Java programs correct is not yet 
solved satisfactorily. Java combines a number of features that pose difficulties 
for a verification calculus: objects and object updates, static initialization, a 
class hierarchy and inheritance, exceptions, and threads. Additionally, Java has 
a large number of language constructs. It is not clear how to integrate these 
features into a proof system that is fast and (relatively) simple to use. 

However, that may depend on the problem domain, i.e. what kind of Java 
programs are verified. Consider smart cards: they are distributed in large num- 
bers (in credit and health cards or mobile phones) , and they are usually security 
critical (money or privacy is lost if the security is broken). And, they can be pro- 
grammed in Java Card, but this is difficult and error prone. So smart cards are 
a very useful area for Java program verification, and, as it turns out, a tractable 
one. 

In this paper we present a calculus for sequential Java that is formally proved 
correct and implemented in the KIV system [12] [3] [23]. Section 2 describes the 
intended problem domain, smart card programming. Section 3 introduces the 
semantics that is the basis for the calculus and the correctness proofs in section 
4. All of them are only presented in examples due to the complexity of Java. 
Section 5 shows an example proof, section 6 compares with other Java proof 
systems, and section 7 summarizes. 

2 Java Card 

Java Card [18] is a variation of Java that is tailored for smart cards. A smart 
card is a plastic card containing a small processor. Smart cards are used in 
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mobile phones, as credit cards, for authentication etc. These processors have very 
limited speed and memory. Typically they are 8-bit processors running at 5 Mhz. 
The most advanced cards have 128 KBytes ROM, 64 KBytes EEPROM, and 5 
KBytes RAM. Often a cryptographic co-processor is included (e.g. with 1024 
Bit RSA and 3-DES). This means that the complete JVM and all applications 
must fit into some dozen kilobytes of memory. 

Java Card has the same language constructs (i.e. expressions and statements) 
as Java, but omits all features that make the JVM big and slow. It does not sup- 
port threads, garbage collection, streams, floating point arithmetic, characters 
and strings, and integers. Essentially, Java Card is sequential Java with fewer 
primitive data types and a much smaller API. However, Java Card programs 
often use expressions like postfix increment or compound assignments, and rely 
heavily on byte and short arithmetic. This means that these constructs must be 
supported and modeled precisely. 

An interesting smart card application is the storage of electronic tickets (e.g. 
railway tickets). If the smart card contains only genuine tickets they can be 
inspected and invalidated offline, i.e. without access to a central data base. This 
goal (only genuine tickets) can be achieved by access control and cryptographic 
protocols. In this scenario the smart card owner must be considered hostile 
because he has an interest to load forged or copied tickets onto the card. So the 
owner may not modify or read the code or data (the code itself is not secret, 
but cryptographic keys are) . This is achieved by loading the program in a secure 
environment and by setting suitable access rights. The Java Card program on 
the smart card manages the tickets, and performs the steps of the cryptographic 
protocols. A typical program (including loading of tickets via internet and offline 
transfer of tickets) has about 1200 lines of code and about 40 methods. This does 
not include cryptographic operations like RSA encryption, digital signatures etc. 
that come from a predefined library (and are defined in the Java Card API). 

3 A Natural Semantics for Sequential Java 

Several different Java semantics exist, e.g. [5] [8] [26]. They differ in the used 
formalism, the number of supported Java constructs, in the assumptions made, 
and in the level of detail for auxiliary operations 1 . However, the basis for every 
formal semantics is the Java Language Specification [19]. Different formalisms 
can be used for the semantics: denotational semantics, abstract state machines 
(ASMs), Structural Operational Semantics (SOS), natural semantics, and others. 
(There is also the further notion of small-step and big-step semantics.) Maybe 
the “best” semantics is one that is closest to the informal descriptions in the Java 
Language Specification, so that people who are not experts in formal methods 
have a possibility to understand it. For this reason we choose a natural (big-step) 
semantics. 

1 Perhaps one should distinguish between a formal semantics - one written in a logic 
with a precise semantics and syntax, parsed by a computer, and a mathematical 
semantics that uses mathematical notation, but does not adhere to a precise syntax. 
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The semantics of a Java statement is a ternary relation: a statement a trans- 
forms an initial state st = vxh consisting of a variable mapping v (as in classical 
predicate logic) and a heap h into a final state st' = v' x h' consisting of a new 
variable mapping v' and a new heap h' , stlal tds st' . In SOS this is often writ- 
ten as ( a,st ) — > st' . If a does not terminate there is no final state st'. If a 
terminates there is exactly one new state st' , because Java Card is determin- 
istic. (The semantics can also be viewed as a transition system that (stepwise) 
transforms states.) The relation .[.L , . is annotated with the list of class and 
interface (type) declarations tds that comprise the Java program. The semantics 
of a Java expression e additionally includes a result value, st[el tds st' x val (or 
written as ( e,st ) — > ( vafst ') ). The variable mapping v contains values for 
the local variables of the program; they are identified with logical variables. The 
heap h contains the object fields (indexed by a reference and a field name) and a 
‘reserved’ reference with ‘reserved’ fields for static fields, the initialization state 
of classes, and whether currently a jump ( abrupt transfer of control , e.g. when 
an exception is thrown) happens or whether evaluation proceeds in the normal 
manner. No other ingredients are needed to describe the state. The heap is spec- 
ified algebraically, so that the semantics of Java is defined relative to all models 
of this specification. Evaluation of statements and expressions is described in- 
ductively by reduction rules, the semantics is then the smallest set of triples 
•Htds- dosed under the rules for the relations. The construction guarantees that 
the smallest set is well defined (no negative occurrences of the relations) . 



h[mode\ normal , . h[mode] = normal . . 

v x /i[e]u x h x 1 v x x h x l v 

v x h\e\vo x ho x ro ro = null V ho[mode\ normal 
vo x /io[throw new NullPointerException()\\vi x hi (3) 
v x h[e.f]vi x hi x J_ 

v x /j[e]i>o x ho x ro ro ^ null A ho[mode ] = normal . 
v x h[e.f]vo x h 0 x h 0 [r 0 x /] 

Fig. 1. Semantics rules for jump (1), literal (2), and instance field access (3, 4). 



Figure 1 shows four simple rules. The jump rule (1) states that in case of an 
abrupt transfer of control (when an exception is thrown, or a return, break, 
or continue statement is encountered) any expression is skipped. The heap h 
stores Java values that can be accessed with keys (normally a pair of an object 
reference and a field name, but there are some special keys and special values: one 
special key mode is used to record the evaluation mode, and h [mode] looks up 
the value in the heap. So h.[mode\ ^ normal means that no normal evaluation 
takes place. The expression is not evaluated, the variable mapping and heap 
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remain unchanged, and a dummy value _L is returned. A literal (2) is evaluated 
if the mode is normal. The value is the literal evaluated under the current variable 
mapping l v (in our case literals may contain algebraic expressions with variables), 
everything else remains unchanged. In case of an instance field access (3) a 
NullPointerException is thrown if the invoking expression is null (if initially the 
mode was not normal the evaluation of e is skipped due to the jump rule; if 
during evaluation of e an exception occurs the throw statement will be skipped 
due to the throw rule). Otherwise the value is looked up in the heap using the 
computed reference r o together with the field name ( ho[ro x /]) (4). 

We consider another example: the instance method invocation (see Fig. 2). 
It has three rules, the first in case the invoking expression is null, the second 
for exceptions during evaluation of the arguments or the body, or in case the 
body completes without a return (this is possible for void methods). Only the 
third rule is shown. First, the invoker and the arguments are evaluated, then the 
arguments are bound and the method body a is evaluated. If the body completes 
with a return ( is jreturrumode(h n + 1 [mode])) the mode is set back to normal 
(K+i [mode, normal ]) and the value {h n +i [mode[.val) returned. The main point 
is that the real problem of the rule, the dynamic method lookup, is completely 
hidden in the definition of getMethod (an algebraically specified function). Every 
formal Java semantics must specify precisely how this method lookup works (e.g. 
what happens in case of a cyclical class hierarchy). The same holds for all other 
definitions. So the semantics is much more (complicated, longer) than just the 
rules. This makes it very difficult to compare two semantics that are formally 
defined in different proof systems. 



v x h[ejvo x ho x r 0 vo x ho[ei\vi x hi x n ... v n -i x h n -i \en\v n x h n x r n 
ro ^ null A h n [mode] = normal 

(vn)2\\Zl n Sthis x h n {a\vn+i x h n+i is.return.mode(h n + i [mode]) 

v x h\e.m{ei , . . . , e n )\vn x hn+i [mode, normal] x h n +i [mode].val 

m(x i, . . . ,x„) {a} = getMethod(classOf(ro), m, tds), 

Fig. 2. The third rule for instance method invocation. 



All in all 24 expressions and 23 statements are specified. In other semantics 
the count may differ due to decisions what are considered different constructs. 
Seven of the 23 statements are not part of Java. They are introduced because they 
are used in the calculus, static and endstatic are used for the initialization 
of super classes and to capture exceptions during initialization; target and 
targetexpr define a target for return statements, finally and endfinally 
are used to describe the beginning and end of a finally block, and catches holds 
a list of catch clauses. The full semantics of the language constructs is described 
in 123 rules. This is a large number, but every rule describes exactly one case 
that may occur during evaluation. About 50 nontrivial definitions with several 
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hundred axioms are specified algebraically, plus the heap, and the primitive 
types for bytes, shorts, and the bitwise integer operations. A pretty printing 
has more than 50 pages. Obviously it is a nontrivial task to make sure that the 
specification captures the intended Java semantics in every little detail. 

Comparison to other formal semantics. David von Olreimb [25] defines a natu- 
ral semantics for a subset of Java (9 statements and 12 expressions) in Isabelle 
with a deep embedding using higher order logic. It is interesting to note that the 
notion of a ‘state’ is more complicated than our state, even though a reduced 
language is used. The state contains a store for local variables, and an explicit 
exception status; the environment contains not only the Java classes, but also 
local variables. Borger and Schulte [5] (later expanded in [24]) give an ASM se- 
mantics that also includes threads, but is not formalized in a proof system. Usage 
of ASMs requires more notational overhead, because stacks for local variables 
and a pointer into the program code is needed to model program evaluation. 
Both use a very short notation that is sometimes difficult to read, and both aim 
more at meta properties of the Java language than at source code verification of 
concrete programs. Therefore they omit e.g. most operations on primitive data 
types. The LOOP project (Jacobs et. al. [17] [13]) uses a coalgebraic approach 
(and a formalization by a shallow embedding in PVS) where the state includes 
besides the heap also a stack for method calls and a memory for static data. 
So compared to others, this semantics seems to be more simple (concerning the 
state and the used formalism, algebraic specifications) and may be easier to 
understand for non-experts. 

4 A Calculus for Java Card 

4.1 Sequents and Dynamic Logic 

The calculus is a sequent calculus for dynamic logic [10]. Dynamic logic extends 
predicate logic with two modal operators, box [ . ] . and diamond ( . ) . The 
intuitive meaning of (H; a) p is: with initial heap H (a variable) the Java state- 
ment a terminates, and afterwards p holds. <p is again a formula of dynamic 
logic, i.e. it may contain boxes or diamonds. The meaning of [H; a] p is: if a 
terminates then afterwards p holds. The formal semantics is 

A,tds,v |= (H;a) p :<t=> 3 v',h'.v x v(H)[a] tds f/ x h! and A, (r/)jj |= p 

(H; a) p holds in an model A with Java type declarations tds and variable map- 
ping v iff there exists a new variable mapping v' and a heap h! such that a with 
initial mapping v and initial heap n(H) computes v' and h! (this means that a 
terminates) and afterwards p holds under the new variable mapping where the 
new heap h' is bound to the variable H. A sequent pi , . . . , p m b ipi , . . . , ip n con- 
sists of two lists of formulas (often abbreviated by r and A) divided by b and is 
equivalent to the formula p\ A ... A p m — » ipi V ... V ip n . pi, . . . p m can be 
thought of as preconditions, while one of ip \ , . . . , ip n must be proved. A Hoare 
triple {p}a{tp} can be expressed as p b [H; a\ip or p b (H; a) ip if termination is 
included. However, more things can be expressed (e.g. program equivalence). 
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4.2 Some Example Rules 

The calculus essentially has one rule for every Java expression and statement, 
plus some generic rules. It works by symbolic execution of the Java program 
from its beginning to its end (i.e. computation of strongest postcondition). This 
means it follows the natural execution of the program, and is much more intu- 
itive than inventing intermediate values (as in a Hoare calculus) or computing 
weakest preconditions (by evaluating a program from the end to the start). 
Nested expressions and blocks are flattened to a sequence of simple expressions 
and statements that can be executed directly. Obviously, this flattening must 
obey the evaluation order of Java. The additional Java statements mentioned in 
the last section are used to mark the end of a block. A box or diamond never 
contains isolated expressions but only statements (e.g. an expression statement). 
The result of an expression is ‘stored’ with an assignment to a local variable. 
Most of the rules are applicable if the program occurs on the left or on the right 
hand side of the turnstyle K and they are applicable for boxes and diamonds. 
An instance field assignment has three premises: 

1. r, H[mode\ ^ normal b ip, A 

2. r, H[mode\ = normal, e = null 

b (H; throw new NullPointerExceptionQ; ) tp, A 

3. r, Hlmode ] = normal, e ^ null, Hr, = H\e x f, en] 

b (H 0 -,x = e 0 -,) p[H/H 0 },A 

r b (H- x = ( e.f = e 0 ); ) p, A 

/ is the field name, e the invoking expression. The rule is only applicable if e 
and eo are basic expressions, either local variables or literals. If the mode is not 
normal the expression is skipped (first premise). If the invoking expression is 
null a NullPointerException is raised (second premise). Otherwise the heap 
H is modified by setting the field ex/ to the value of eo (H[e x /, eo]). Then 
the computation continues with the new heap (bound to Hq, a new variable). 
Since e and eo are local variables or literals they require no further evaluation, 
but can be taken directly as values. If they are other Java expressions they have 
to be flattened first. 

The flattening rule works as follows: 

1. For an expression x = e select the immediate subexpressions e\, ... ,e n of e. 

2. Find the first e, that is not a local variable or a literal, and that does not 
cause a variable conflict (see case 4) . 

3. Replace e* in e by a new variable y yielding e' and add the assignment y = ei 
before x = e! . 

4. A variable conflict occurs if e, contains an assignment to a variable that 
occurs in e\, . . . , e*- 1, e.g. in x * (x = 3) . In this case a renaming is nec- 
essary. 

After a finite number of applications the algorithm will return a list of assign- 
ments where every subexpression is either a local variable or a literal. Then a rule 
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for this expression is applicable. The test of an if, the expression of a switch, 
return, or throw can also be flattened in this manner (but not the test of a 
while, do or for). A block is also flattened: 

1. r, H[mode ] ^ normal b tp, A 

2. r, H[mode\ = normal b {H\a' 1 \x_/y}) a' n [x_/y\) <p,A 

r b ( H ; {cti ...a n }) tp, A 

a, are the top level statements of the block, x the local variables declared in 
the block, and y new variables, a) is a, except for a local variable declaration. 
ty x = e becomes an assignment x = e. Note that this is not legal Java if e 
is an array initializer, but we treat it as a normal expression. The replacement 
with new variables ensures that the variables really behave as local variables. A 
similar flattening happens for the try statement: 

1. r, H[mode\ ^ normal b ip, A 

2. r, H[mode\ = normal b ( H\a catches (catches) finally(/?)) tp, A 
r b (H; try a catches finally (3) tp,A 

The list of catch clauses catches is transformed into an additional Java state- 
ment catches (catches), and the finally clause is transformed into an additional 
Java statement finally(/3). In this manner expressions and statements can be 
flattened. Loops can be unwound and treated by induction. 




1. r,mode(st) ^ normal b tp, A 

2. r, e = null,mode(st) = normal b (H; throw new NPEQ) <p,A 

3 . r, e null,mode(st) = normal b classOf(e, st) £ {ci, C2, C3}, A 

4 . f, e ^ null,mode(st) = normal, class O f (e, st) £ {01,03}, 
this' = e,z = es b ( H;a'i ) (H; targetexpr(a;)) tp, A 

5 . T,e^ null,mode(st) = normal, class O f (e, st) £ {02}, 

this 1 = e,z = es b (H\ targetexpr(a;)) tp, A 

F b (H-,x = e.m(es)) tp,A 

Fig. 3. Example class hierarchy and rule for instance method invocation. 



As a last example we show the rule for an instance method invocation. This 
rule has a variable number of premises depending on the number of possible 
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methods that can be invoked. Figure 3 shows a class hierarchy where class ci 
contains a method declaration m with a body mi that is overwritten in class ci 
with another body m2. If e.m(ei, . . . , e n ) is the method invocation the correct 
method body to invoke depends on the runtime type of e. e must be a local 
variable or literal and should be a reference 7^ null. If e is a reference to an 
object with type Ci or C3 then method m\ is invoked; if the type of e is C2 then 
method m2 is invoked; the third premise ensures that the type of e is either Ci, C2, 
or C3. Note that there is no possibility to omit this premise. A type correct Java 
program guarantees this if the heap conforms to the program, but the calculus 
does not enforce the latter. The heap can contain arbitrary entries that have 
nothing to do with the classes and declarations of the program. Therefore it is 
necessary to prove that the runtime type of e is ‘legal’. Together with a ‘jump’ 
case and a null invoker the rule has five premises in this instance (Fig. 3). In 
premises 4. and 5. the parameters ei,...,e„ (that must be local variables or 
literals) are bound to new variables z, a new variable this 1 is introduced for 
this and bound to e, in the method body the formal parameters are replaced 
with the new variables yielding a', and a new statement targetexpr(x) is added 
that will catch a return statement and bind x to the returned value. 

4.3 Interactive Proofs 

One of the most important features of the calculus is that it is well suited for 
interactive proofs, much better - we feel - than a Hoare or wp calculus. Because 
a formula containing a Java statement is only one formula among others, the 
user can mix predicate logic rules (case distinctions, quantifier instantiations, 
cut, etc., or advanced rules like rewriting or simplification) freely with Java rules. 
This helps to reduce the size of non- Java formulas during the proof. Furthermore, 
a method call (or any other statement) can be either evaluated, or one or several 
lemmas for the method call can be applied at different points in the proof. The 
reason is that programs can appear on both sides of the turnstyle b so that it 
is possible to argue that if program a computes x then program (3 computes y. 
The following proof rule is valid: 

(H-,a) x = y,y\x/y\,r b ip\x/y\,A 
( H;a ) ip,T b (H;a) ijj,A 

We know (H; a) ip, i.e. a terminates and afterwards ip holds (this can be a lemma 
about a) . a can only modify a number of variables x (the assigned variables of 
a and the heap H) and these variables describe the state exactly. Therefore 
we can introduce new variables y that hold the result and then we know that 
<p[x,y] holds (ip with x replaced with y). Now we want to prove (H;a) i/) and 
we know that a computes y. Therefore we can discard a on the right hand 
side of the turnstyle b and it remains to prove that i/j\x,y\ holds. This is the 
typical situation if a lemma is used. But the program a does not disappear from 
the sequent. It remains in the antecedent and later the user can apply another 
lemma that introduces another property. Nothing similar is possible in a Hoare 
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calculus. Another advantage is that induction can be used for loops or recursive 
methods. This means the user has more freedom to structure proofs. 



4.4 Correctness of the Calculus 

The proof rules are specified in KIV and their correctness with respect to the 
semantics has been proved. Since the calculus introduces several new operations 
(the notion of free and assigned variables, replacement of variables, flattening of 
expressions, formulas, sequents etc.) the complete specification is considerably 
larger than just the Java semantics. Especially operations that are defined for all 
expressions or statements have lots of axioms, and proofs for these operations 
require the most time. Furthermore, the semantics’ relations for expressions, 
expression lists, statements, and statement lists are mutually recursive and must 
be formulated and proved for all four relations at once. The most time consuming 
proofs are concerned with the correct definition of free and assigned variables (the 
semantics of a Java statement depends only on the values of the free variables, 
and only assigned variables can be changed) because the definitions should not 
include superfluous variables. Other important proofs concern the correctness of 
variable replacement and flattening. In comparison the rule for instance method 
invocation is quite simple to prove because in the semantics and in the proof rule 
the method lookup just travels up in the class hierarchy. All 57 rules have been 
proved correct. The specification and verification effort required several months 
of work. Currently the calculus is not (relatively) complete for two reasons: 
First, there is no possibility to argue about the number of recursive method 
calls. Experience shows that usually induction on the used data structure is 
sufficient (a counter that becomes smaller, or the length of a list that decreases). 
However, it is not possible to prove that a method that just calls itself (void 
m() {m() ; >) does not terminate. Second, the semantics does not depend on 
type correct programs (or programs that pass a Java compiler the compiler 
checks more than just type correctness). But for verification we are interested 
only in type correct programs, and for type correct programs more efficient rules 
can be designed. (They are correct but incomplete for type incorrect programs.) 

As can be imagined several errors were found during verification. Most of 
them are errors only for type incorrect programs. For example, the definition 
of free variables must handle the case that a local variable declaration occurs 
outside a block or that a local variable occurs outside the scope of a local variable 
declaration. Other errors were more serious because they concerned type correct 
programs: 

1. The third premise in the instance method invocation was missing (that 
checks that the runtime type of the invoker is correct, see Fig. 3). As men- 
tioned above this is important even for type correct programs because the 
heap may not conform to the program. 

2. The flattening rule contained no check for variable conflicts, y = x * (x = 
3) ; was flattened to z = (x = 3) ; y = x * z; which is wrong. (A renam- 
ing is needed: xO = x; z = (x = 3) ; y = xO * z;). 
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3. A similar problem occurred for the postfix increment: x = y++ was trans- 
formed into x = y; y = y + 1 ; which is wrong for x = x++ ; (the right 
hand side is fully evaluated before the assignment occurs). 

These errors were found because the verification of the proof rules failed. How- 
ever, some errors were found in the semantics as well. 

1. first active use was not handled correctly in the semantics rules, i.e. whether 
static initialization occurs before or after the arguments are evaluated, (com- 
pound assignment to static field and new class: before evaluation of argu- 
ments, simple assignment to static held and static method invocation: after 
evaluation of arguments.) 

2. The semantics rules for compound assignment failed to cast the result back 
to byte or short if the right hand side was byte or short. (In byte b = 
127; b += 1; the result is (byte) — 128.) 

These errors were found because the verification of the proof rules also failed, 
and analysis revealed the errors to be in the semantics. However, both semantics 
and calculus could be wrong. It is possible to validate the semantics by ‘running’ 
test programs in KIV (automatically applying the proof rules) and comparing 
the output with a run of a Java compiler and JVM (currently 150 examples), 
and this certainly increases confidence in the semantics, but who would think 
about writing programs like x = x++ ; ? 

5 An Example Program 

The aim of the example is to show the ‘look and feel’ of the calculus for a small 
example that involves a for loop, exceptions and abrupt termination of the loop. 
It is typical for Java Card programs to use this programming style. We consider 
the Java Card application for storing tickets mentioned in section 2. Since the 
available memory for a Java Card program (an applet) is severely limited the 
maximal number of tickets that can be stored must be fixed in advance. The 
missing garbage collector means that storage cells cannot be reclaimed. Therefore 
it is usual programming practice to allocate all objects when the applet is loaded 
onto the smart card, and to reuse these objects. Our applet has a capacity of 20 
tickets that are stored in an array. A field free indicates if the entry is free or 
not. If a ticket is loaded the value is set to false, if it is deleted after usage the 
entry is set back to true. 

class Ticket {boolean free = true; (rest of class)} 

public class Cardlet extends Applet { 
final static byte MAX = 20; 

Ticket [] tickets = new Ticket [MAX] ; 

Cardlet () { 

for(byte c=0;c<MAX; C++) tickets[c] = new TicketO;} 

(rest of class)} 
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A Java Card applet works as follows: An install method is called once when 
the applet is loaded onto the card. This method typically calls the constructor. 
All data (fields, objects, and arrays) is stored permanently in the EEPROM of 
the smart card. When the smart card is inserted in a reader and the applet is 
selected, a method select is called once. Afterwards all communication takes 
place through a process method. The JVM receives the input, a sequence of 
bytes, stores them in a byte array and calls the process method with this array, 
process normally computes an answer that it stores in the byte array, and that 
will be sent back to the terminal by the JVM. Another possibility is to throw 
an exception that is converted by the JVM into an error message. 

The following method can be used somewhere in the applet to find a free 
position: 

byte findFree () { 

for (byte c=0; c < MAX; C++) 

if (tickets [c] . free) return c; 

ISOException . throwlt (SW_FILE_FULL) ; 

> 

If no free position is available an exception is thrown (without creating a 
new exception object!) from the predefined method ISOException. throwlt. 
This exception ends the process method and results in an error message to be 
sent to the terminal (SW_FILE_FULL) . If the findFree method is used several 
times in the code it is good proving practice to formulate some lemmas about 
its behaviour and re-use them wherever possible. For example, 

findFree-install : install(H) b (H; by = cardlet.fmdFreeQ;) install(H) 
findFree-tlrrow : 

#tickets(H) = b2i(MAX), install(H), H[mode] = normal 
b (H; by = cardlet.fmdFreeQ;) ISOException(SW_FILE_FULL, H) 

findFree-ok : 

#tickets(H) < b2i(MAX), H = Ho, install(H), H[mode] = normal 
b (H; by = cardlet.fmdFreeQ;) (H = H 0 A free_ticket(b2i(by), H)) 

The method assumes that the array entries are not null. This is the case after 
installation. Hence an invariant install^ H) is needed for the applet. This invariant 
will contain other properties of the applet that should hold before and after 
every communication step (i.e. before and after every call of process), including 
logical properties related to the cryptographic protocols. Finding this invariant 
is not trivial, but essential for the correctness of the applet. install( H) is a user 
defined predicate for the heap. The second property, findFree-throw, states that 
the method will throw an exception SW_FILE_FULL if the number of tickets stored 
in the heap is already MAX (^tickets(H) = b2i(MAX), b2i converts a byte into 
an integer). Here we can assume that the invariant holds, and we must assume 
that no abrupt transfer of control happens initially (H[mode] = normal) because 
then the method call will be skipped. Finally, findFree-ok states that the method 
will return a free position if there is one. 
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We show the proof for findFree-ok. Method call and initialization of the for 
loop results in 



H = H 0 , this = cardlet, c = 0, H[mode] = normal, 

#tickets(H) < b2i(MAX), install(H) 
b (H;for(c < MAX; c ++) if (this. tickets [c]. free) return c; else { }) 
(H;ISOException.tlrrowIt(SW_FILE_FULL);) 

(H;targetexpr(by)) (free_ticket(b2i(by), H) A H = H 0 ) 

The for loop contains no initialization so it can be unwound; cardlet is a ref- 
erence to an object of type Cardlet that becomes the value of this inside the 
method. Now we use induction on |MAX — c| and generalize the goal by replacing 
c = 0 with 0 < c A c < MAX (this is done automatically), and add the formula 
#tickets(H[cardlet - tickets]. refval, b2i(c)— 1, H) = b2i(c) stating that the num- 
ber of tickets from 0 to c — 1 in the array is c (this means that all tickets below 
c are not free). H[cardlet - tickets]. refval returns the reference that is stored in 
the tickets field of the cardlet object. This property is needed to prove that 
the loop counter c can never reach MAX. Then we unwind the for loop once 
and obtain 

Ind-Hyp, . . . (other preconditions) . . . 
b (H;if (b2i(c) < b2i(MAX)) 

if (this. tickets [c]. free) return c; else { } c ++;) 

(H;for(c < MAX; c ++) if (this. tickets [c] . free) return c; else { }) 
(H;ISOException.throwIt(SW_FILE_FULL);) 

(H;targetexpr(by)) (free_ticket(b2i(by), H) A H = Ho) 

If the first if test is true and the second one is false we obtain after the postfix 
increment C++ 

Ind-Hyp, Co = i2b(b2i(c) + 1), -> H[r 0 - free].boolval 
. . . ( other preconditions) . . . 

b (H;for(co < MAX; co++) if (this. ticketsfco]. free) return c 0 ; else{}) 
(H;ISOException.throwIt(SW_FILE_FULL);) 

(H;targetexpr(by)) (free_ticket(b2i(by), H) A H = H 0 ) 

The formula on the right hand side of b (with the for loop) is identical to the 
formula where the induction started, except that c is replaced by Co- This means 
we can apply the induction hypothesis (This requires proving that no overflow 
occurs for the byte value c.), and obtain a program formula one the left hand 
side of b. The result is an axiom: 

(H;f or(c 0 < MAX; c 0 ++) . . . b (H;f or(c 0 < MAX; c 0 ++) • • • 

Aside from the rather longish sequents the proof proceeds as a proof done on 
paper. The same principle (induction and unwinding of the loop) can be used 
for while or do loops. In other proofs only the lemmas for the findFree method 
are used. This allows a nice structuring of the proofs. 
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6 Comparison to Other Proof Systems for Java 

Java Card verification in KIV seems to be unique in that an existing prover was 
extended to incorporate a Java Card calculus. In the KeY project [16] [20] a new 
prover is developed from scratch; Olreimb [27] [25] models a formal (operational) 
semantics and a Hoare calculus (for a subset of Java) in Isabelle; in the LOOP 
project [16] [17] [14] Java together with JML [6] annotations are translated into a 
formal (denotational) semantics enriched by proof rules for a Hoare- and weakest 
precondition calculus in PVS; the Krakatoatool [21] translates into Coq; Jack [7] 
into a prover for the B method. The KIV approach has two advantages compared 
to the others: First, an already good prover can be used for the non-Java parts; 
second, the prover can be tailored to the goals that arise in Java verification. 
This includes simple things like pretty printing to make the goals more readable, 
but also special heuristics and simplification strategies (e.g. a special treatment 
of the heap). The drawback is, of course, that access to the internals of the prover 
is necessary. 

KeY also uses a dynamic logic, but the calculus is not proved correct w.r.t. a 
formal semantics. The three main differences are: exceptions are modeled as non- 
termination, blocks are not flattened (though expressions are), and there is no 
explicit heap. The last two lead to more complex formulas: programs contain 
a ‘prefix’ representing nested blocks (including try catch blocks) and ‘updates’ 
to objects to cope with aliasing. On the other hand, omitting the heap may 
help to prove that a method does not modify some objects. Olreimb uses a pure 
Hoare calculus that is tailored for backward reasoning (i.e. computes weakest 
preconditions), and has proved its correctness and completeness in Isabelle. One 
specialty of the calculus is that the state must always conform to the (type cor- 
rect) program. This may require unnecessary proof work when the consequence 
rule is used (the Java rules preserve conformity), and it is not clear how theo- 
rems that are proved for a library or API class can be reused (because the new 
state contains new objects that do not conform to the original classes). We do 
not require this conformity. The LOOP project also uses a Hoare calculus and 
weakest preconditions (formally proved correct). As mentioned earlier, we feel 
that a dynamic logic allows more flexibility. It is interesting to note that Olre- 
imb uses quadruples as pre- and postconditions, while LOOP uses 8-tuples. So 
it seems that the calculus presented here has the most simple structure (a heap 
and two modal operators for the programs). 

Another difference to most other approaches is that in KIV the user plays 
an important role and is expected (and encouraged) to interact with the system 
to keep the proofs manageable. In KeY, LOOP, Krakatoa, and Jack the prover 
is viewed as a back end system that is best used fully automatically. Ideally, 
the prover is fed with some Java goals, generates proof obligations that contain 
no longer Java statements, and proves these goals automatically. However, this 
works only up to a given size of the formulas. Better support for interactive 
proofs can help to reduce the size while proving, but this requires (currently) a 
rather experienced user. 
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7 Conclusion 

We presented (in excerpts) a formal semantics and calculus for Java Card (es- 
sentially sequential Java) that supports all language constructs. The semantics 
is a natural (big-step) semantics, which is adequate for deterministic sequential 
programs. The semantics is defined relatively to an algebraic specification of a 
heap and Java’s primitive types. The complete specification is big, but Java is 
a complex language. The calculus is a sequent calculus for dynamic logic that is 
more expressive than a Hoare calculus and - we feel - better suited for interac- 
tive proofs. The calculus has been proved correct formally with KIV, and is also 
implemented in KIV. Currently, KIV seems to be the only existing prover that 
was extended for a Java Card calculus. 

The main application area is in the context of smart cards where interest- 
ing and security critical (because money and privacy is involved) e-commerce 
applications like electronic ticketing make a formal verification very desirable. 
It must be proved that the program correctly implements a cryptographic pro- 
tocol that guarantees the security of the application. Without formal methods 
it is very difficult to assess the correctness and security of an interesting smart 
card application 2 . The programming style in Java Card requires that certain 
features (byte and short arithmetic, arrays, for loops, exceptions etc.) are mod- 
eled precisely and handled efficiently in the prover. Experience shows that the 
main difficulties are reasoning about bytes, shorts, byte arrays, cryptographic 
methods, and invariants that hold between communications. 

One can ask why a prover should support all the complex features of sequen- 
tial Java. There are three reasons. First, Java Card programs typically use these 
features; second, to show people who are critical towards formal methods that 
the field has reached at least that maturity; third, because formal methods do 
not scale up by themselves. It is not clear if a double sized program requires 
double effort or more. And even if the increase is linear every prover will even- 
tually fail (see e.g. [17]: “PVS can run for hours without completing the proof, 
or it can crash because the proof state becomes too big.”). So work has still to 
be done to reduce the complexity of formal proofs. 
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Abstract. This paper characterizes refinement of state-based software 
components modelled as pointed coalgebras for some Set endofunctors. 
The proposed characterization is parametric on a specification of the 
underlying behaviour model introduced as a strong monad. This provides 
a basis to reason about (and transform) state-based software designs. 
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1 Introduction 

Component-based software development [15, 16] emerged as a promising para- 
digm to deal with the ever increasing need for mastering complexity, software 
evolution and reuse. From object-orientation it retains the basic principle of 
encapsulation of data and code. The emphasis, however, is shifted from (class) 
inheritance to (object) composition to avoid interference between the former 
and encapsulation and, thus, paving the way to a development methodology 
based on third-party assembly of components. In [3,2], the authors proposed a 
coalgebraic characterization of software components as specifications of state- 
based modules, encapsulating a number of services through a public interface 
and providing limited access to an internal state space. Component persist and 
evolve in time, being able to interact with the environment during their overall 
computation. This piece of research has been driven by two key ideas: first, 
the ‘black-box’ characterization of software components favors an observational 
semantics; secondly, the proposed constructions should be generic in the sense 
that they should not depend on a particular notion of component behaviour. 
This led both to the adoption of coalgebra theory [14] to capture observational 
semantics and to the abstract characterization of possible behaviour models ( e.g ., 
partiality or (different degrees of) non-determinism) by strong monads acting as 
parameters in the resulting calculus. 

Within this approach, briefly reviewed in section 2, a set of component con- 
nectors have been identified and their properties established as bisimilarity equa- 
tions with respect to a generic behaviour model. Actually, the corner stone of 
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our ‘components as coalgebras’ approach is the use of coinduction to prove 
results, where ~ is the appropriate bisimilarity relation, as a basis for reasoning 
and transforming component-based designs. This paper provides a basis to ex- 
tend the approach toward the inequational side through the discussion of suitable 
notions of refinement. 

In broad terms refinement can be defined as a transformation of an ‘abstract’ 
into a more ‘concrete’ design, entailing a notion of substitution, but not neces- 
sarily equivalence. There is, however, a diversity of ways of understanding both 
what substitution means, and what such a transformation should seek for. In 
data refinement, for example, after Hoare’s landmark paper [8], the ‘concrete’ 
model is required to have enough redundancy to represent all the elements of 
the ‘abstract’ one. This is captured by the definition of a surjection from the 
former into the latter (the retrieve map). Also substitution is regarded as ‘com- 
plete’ in the sense that the (concrete) operations accept all the input values 
accepted by the corresponding abstract ones, and, for the same inputs, the re- 
sults produced are also the same, up to the retrieve map. This means that, if 
models are specified, as they usually are in model- oriented design methods like 
Vdm[ 10], in terms of pre and post-conditions, the former are weakened and the 
latter strengthened, under refinement. In object- orientation, on the other hand, 
substitution is expressed in terms of behaviour subtyping [11] capturing the idea 
that ‘concrete’ objects behave similarly to objects in the ‘abstract’ class. Finally, 
refinement in process algebras is usually discussed in terms of several ‘observa- 
tion’ preorders (see, for example, [7]), most of them justifying transformations 
entailing reduction of nondeterminism. 

In general, refinement correctness means that the usage of a system according 
to its ‘abstract’ description is still valid if it is actually built according to the 
‘concrete’ one. What is commonly understood by being a valid usage is that 
the corresponding observable consequences are still the same, or, in a less strict 
sense, a subset thereof. The exact definition, however, depends on the underlying 
behaviour model, which, in our approach to component modelling, is taken as 
a specification parameter. Therefore, the main contribution of this paper is a 
semantic characterization of refinement for state-based components, parametric 
on a strong monad intended to capture components’ behavioural models. 

After a brief review of the component calculus, in section 2, the paper dis- 
cusses two levels of component refinement: the interface level, concerned with 
what one may call plugging compatibility , in section 3, and the behavioural one in 
section 4, which introduces forward and backward morphisms as refinement ‘wit- 
nesses’, and section 5 which builds on them to propose a family of refinement 
preorders. Section 6 proves soundness of simulations to establish behavioural 
refinement. A few examples, along with some prospects for future work, are 
presented in section 7. 

2 Components as Coalgebras 

In [3, 2] software components and connectors have been characterised as dynamic 
systems with a public interface and a private, encapsulated state. A typical 
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example is LBuff: a connector modelling a buffered channel which occasionally 
looses messages, as represented below: 



I = M + 1 



LBuff 



0 = 1 + M 

The put and pick operations are regarded as ‘buttons’ or ‘ports’, whose signatures 
are grouped together in the diagram (M stands for a message parameter type, 
1 for the nullary datatype and + for ‘datatype sum’). One might capture LBuff 
dynamics by a function ai_Buff : U x / — > V{U x O ) where U denotes the 
space state. This describes how LBuff reacts to input stimuli, produces output 
data (if any) and changes state. It can also be written in a curried form as 
«LBuff : U — > V(U x O) that is, as a coalgebra [14] of signature U — > T U 
where functor T captures the transition ‘shape’: 

T = "P(ld x O) 1 (1) 

Built in this ‘shape’ is the possibility of non deterministic evolution captured 
by the use of V , the finite powerset monad. Concretely, LBuff is defined over 
U = M*, with nil as the initial state, and dynamics given by 

a LBu ff(u, put m) = {(u, i\ *},(m : u, L\ *)} 
ai_Buff(w, pick) = {(tail u, l 2 (head u))} 

where put m and pick abbreviates l\ to and 12 *, respectively. 

Non determinism, capturing the occasional loss of messages, is a possible 
behavioural pattern for this buffer, but, by no means, the only one. Other com- 
ponents will exhibit different behaviour models: actually genericity is achieved 
by replacing the powerset monad above, by an arbitrary strong monad 1 B. In 
the general case, a component p : I — > O is specified as a (pointed) coalgebra 
in Set 



put : M — > 1 

pick : 1 — > M 



(u p e U p ,a p : Up — * B(U P x O) 1 ) (2) 

where point u p is taken as the ‘initial’ or ‘seed’ state. Therefore, the computa- 
tion of an action will not simply produce an output and a continuation state, 

1 A strong monad is a monad (B ,77, /i) where B is a strong functor and both 77 and p, 
strong natural transformations. B being strong means there exist natural transfor- 
mations rj : T x — =>• T( Id x — ) and : - x T => T(— x Id) called the right and 
left strength, respectively, subject to certain conditions. Their effect is to distribute 
the free variable values in the context ” along functor B. 
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but a B-structure of such pairs. The monadic structure provides tools to han- 
dle such computations. Unit (77) and multiplication (/z), provide, respectively, a 
value embedding and a ‘flatten’ operation to reduce nested behavioural annota- 
tions. Strength, either in its right (r r ) or left (77) version, will cater for context 
information. 

In such a framework, components become arrows in a (bicategorical) universe 
Cp whose objects are sets, which provide types to input/output parameters (the 
components’ interfaces ), and component morphisms h : p — > q are functions 
relating the state spaces of p and q and satisfying the following seed preservation 
and coalgebra conditions: 

h Up = u q and a q • h = B (h x O) 1 'Tip ( 3 ) 

For each triple of objects (/, K , O ), a composition law is given by functor ; 7 K 0 : 
Cp (J, K) x Cp (K, O ) — ► Cp(I, O) whose action on objects p and q is 

p;q = ((u p ,uq) G Up x U q ,a p - q ) with 

a p;q = Up x U q x I - - ■- > U p xIxU q ° pX ' - d > B (U p xK)xU q 

- T -- > B (U p x I< x U q ) --- -- > B (U p x (U q x K)) 

B( ' dXa - > B (U p x B (U q x O)) — BB (U p x (U q x O)) 

- > BB (Up xUqxO) — ► B (U p xUqxO ) 

Similarly, for each object K , an identity law is given by a functor copy^- : 1 — > 
Cp(K,K) whose action is the constant component (* € 1 , 771 x jc). Note that the 
definitions above rely solely on the monadic structure of B. 

In [ 3 , 2 ] a set of component combinators have been defined upon Cp in a 
similar parametric way and their properties studied. In particular it was shown 
that any function / : A — > B can be lifted to Cp as r / n = (* € 1 , 77(1 x B) ' ('d x 
/)). Also defined were both a wrapping mechanism p[f, g] which encodes the pre- 
and post-composition of a component with Cp-lifted functions, and three tensors, 
capturing, respectively, external choice (ES : / + J — > O + R), parallel (Kl : 
IxJ — > OxR ) and concurrent (ffl : I+J+IxJ — > O+R+OxR) composition, 
given components p : I — > O and q : J — > R. When interacting with p EH <7 : 
I + J — > O + R, the environment chooses either to input a value of type / or 
one of type J, which triggers the corresponding component (p or q, respectively), 
producing the relevant output. In its turn, parallel composition corresponds 
to a synchronous product: both components are executed simultaneously when 
triggered by a pair of legal input values. Note, however, that the behaviour effect, 
captured by monad B, propagates. For example, if B can express component 
failure and one of the arguments fails, the product will fail as well. Finally, 
concurrent composition combines choice and parallel, in the sense that p and 
q can be executed independently or jointly, depending on input. Generalized 
interaction is catered through a ‘feedback’ mechanism on a subset of the inputs. 
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3 Interface Refinement 

Component interface refinement is concerned with type compatibility. The ques- 
tion is whether a component can be transformed, by suitable wiring, to replace 
another component with a different interface. As the structure of components 
interface types encodes the available operations, this may capture situations of 
extension of functionality , in the sense that the ‘concrete’ component may in- 
troduce new operations. In the context of object-orientation, this is often called 
design sophistication (rather than refinement) and it is known not to be a congru- 
ence with respect to typical process combinators (see e.g ., [17]). If we structure 
component input and output parameters as an operations’ signature, interface 
refinement can also be seen as induced by a signature morphism, as in e.g., [13]. 

To motivate our own approach, consider, from [3], the following law express- 
ing commutativity of choice: 

pRq ~ (gfflp)[s + ,s + ] (4) 

where s + : I + J — > J + 1 is a natural isomorphism capturing + commutativity. 
The law states that p EB q and q ES p are bisimilar up to isomorphic wiring. This 
means that the observational effect of component piBq can be achieved by q ES p, 
providing the interface of the latter is converted to the interface of the former. 
Such a conversion is achieved by composition with the appropriate wires, leading 
to a notion of replaceability. 

Definition 1 Letp and q be components. We say that p : I — > O is replaceable 
by q : I' — > O ' , or q is a replacement ofp, and write p<q if there exist functions 
w\ : I — > I' and W 2 '■ O' — > O, to be referred to as the replacement witnesses, 
such that 

p ~ q[w 1 ,w 2 ) (5) 

Furthermore, components p and q are interchangeable if each of them is a re- 
placement of the other. Formally, 

p= q iff p< q A q <p (6) 

Clearly, p ES q = q ES p, using isomorphism s + as a wire in both cases. In 
general, p = q whenever w\ and w 2 in (5) are isomorphisms. 

Lemma 1. Replaceability (<) is a preorder on components 

Proof. Clearly, < is reflexive because p < p is witnessed by p ~ p[id, id]. On the 
other hand, if p < q and q < r hold, there exist w\,w 2 ,W 3 and uq such that 
p ~ q[w\,w 2 \ and q ~ r[ws, wq]. Thus, a composition result on wrapping [2] and 
transitivity of ~, entails p ~ r[w\ • W 3 , W 4 • w 2 \, i.e., p <r. □ 

Using < and =, some component laws in [2], as (4) above, can be presented 
in a ‘wiring free’ form. As another example consider the law relating concurrent 
composition with choice, 

r Li ~ l ; (pm q) ~ {pSq) ; r (. 1 “ l 
which gives rise to two replacement inequations: 
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r ti n ; (p II q) < p ES q and (p ffl q) ; r ii n < p ffl q 

Finally, the statement that every component p can replace an inert component 
can be expressed as an interface refinement situation: inert < P- 

Relation <, however, fails to be a pre-congruence with respect to the compo- 
nent operators introduced in [3]. It is easy to check that ES, H3 and SI, as well as 
wrapping are preserved, i.e., if p < p' then, for any q , / and g , p[f,g] <p'[f, 3], 
p ES q < p' ES q and, similarly, for the other two tensors. But things are different 
with respect to sequential composition and feedback. In these cases, the replaced 
expression may even become wrongly typed. 

What p < p' means is that component p can be replaced in any context by 
p'[wi, W2}, for any functions w\,W2 witnessing the fact. The explicit reference to 
them is actually required, something which is not completely satisfactory in a 
refinement situation, although common in similar settings (c/. [17]). 

4 Forward and Backward Morphisms 

Interface refinement is essentially concerned with plugging adjustment. Behav- 
iour refinement, on the other hand, affects the internal dynamics of a component 
while leaving unchanged its external interface: it takes place inside each horn- 
category of Cp. Intuitively component p is a behavioural refinement of q if the 
behaviour patterns observed from p are a structural restriction, with respect to 
the behavioural model captured by monad B, of those of q. To make precise such 
a ‘definition’ we shall first describe behaviour patterns concretely as generalized 
transitions. 

Actually, just as transition systems can be coded back as coalgebras, any 
coalgebra (U,p : U — > T U) specifies a (T-shaped) transition structure over its 
carrier U. For extended polynomial Set endofunctors 2 such a structure may be 
expressed as a binary relation — > p C U x U, defined in terms of the structural 
membership relation SyC U x T U, i.e., 

u — > p v! iff u! Gt P u 

where Gt is defined by induction of the structure of T : 



x €i d y 


iff 


x = y 


x &K_y 


iff 


false 


x£ Ti xt 2 y 


iff 


x G Tl 7Ti y V x Gt 2 tt 2 y 


x g Ti +t 2 y 


iff 


( y = i iy ’ => X £ Ti y’ 

\y = Liy' =>xe T 2 y' 


x £ T Ky 


iff 


3 keK- xe T y k 


x g-pt y 


iff 


3 y £y • X Gt y 



2 The class inductively defined as the least collection of functors containing the identity 
Id and constant functors K_ for all objects K in the category, closed by functor 
composition and finite application of product, coproduct, covariant exponential and 
finite powerset functors. 
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Notice that, given x € U, X G TU and a function h : U — > V, if x Gt X then 
h x Gt T h X, as it may be shown by induction on the polynomial structure, 
resorting to the definition of Gt and functoriality. Similarly, the dynamics of 
p : I — > O, based on functor B( Id x O) 1 , can be expressed in terms of the 
following transition relation: 

u -^—tp u iff ( u , o) Gb (pu) i 

In this setting, a possible (and intuitive) way of regarding component p as a 
behavioural refinement of q is to consider that p transitions are simply preserved 
in q. For non deterministic components this is understood simply as set inclu- 
sion. But one may also want to consider additional restrictions. For example, to 
stipulate that if p has no transitions from a given state, q should also have no 
transitions from the corresponding state(s). Or one may adopt the dual point of 
view requiring transition reflection instead of preservation. In any case the same 
basic question arises: how can such a refinement stituation be identified? 

In data refinement, as mentioned above, there is a ‘recipe’ to identify a re- 
finement situation: look for a retrieve function to witness it. I.e., a morphism in 
the relevant category, from the ‘concrete’ to the ‘abstract’ model such that the 
latter can be recovered from the former up to a suitable notion of equivalence, 
though, typically, not in a unique way. 

In our components’ framework, however, things do not work this way. The 
reason is obvious: component morphisms are (seed preserving) coalgebra mor- 
phisms which are known ( e.g ., [14]) to entail bisimilarity. Therefore we have to 
look for a somewhat weaker notion of a morphism between coalgebras. 

First of all recall that a component morphism from p to q is a seed preserving 
function h : U p — > U q such that 

B (h x id) - Op = a q • (h x id) (7) 

In terms of transitions, equation (7) is translated into the following two require- 
ments (by a straightforward generalization of an argument in [14]): 

u — > p u => h u — > q n u (8) 

7 (i,o) # ( i.o ) , / i / \ 

h u — > q v => 3 U e u. u — > p u A v = h u (9) 

which jointly state that, not only p dynamics, as represented by the induced 
transition relation, is preserved by h (8), but also q dynamics is reflected back 
over the same h (9) . Is it possible to weaken the morphism definition to capture 
only one of these aspects? The answer is given as follows: 

An order < on a Set endofunctor T is defined in [9] as a functor < which 
makes the following diagram to commute: 



PreOrd 

I 

Set 




(JU,<tu) 




Set 



T 



concretely 



U 
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This means that for any function h : X — > Y, T h preserves the order, i.e. 

X\ <TX X2 => (T/l) Xl <t y (T h) X2 (10) 

In the sequel < will be referred to as a refinement preorder. Then, 

Definition 2 Let T be an extended polynomial functor on Set and consider two 
T -coalgebras a : U — > T U and (3 : V — > TV. A forward morphism h : a — > (3 
with respect to a refinement preorder <, is a function from U to V such that 



T h • a < (3 • h. 

Dually , h is called a backwards morphism if 



(3 • h < T h • a 



The following lemma shows that such morphisms compose and can be taken as 
witnesses of refinement situations: 

Lemma 2. For T an endofunctor in Set. T -coalgebras and forward ( respectively , 
backward) morphisms define a category. 



Proof. In both cases, identities are the identities on the carrier and composition 
is inherited from Set. What remains to be shown is that the composition of 
forward (respectively, backward) morphisms yields again a forward (respectively, 
backward) morphism. So, let h : a — > (3 and k : (3 — > 7 be two forward 
(respectively, backward) morphisms. Then 



( forward case) 

T ( k • h) • a 
= { T functor } 

T k ■ (T h ■ a) 

< { h forward and (10) } 

T k • ( (3-h ) 

= { • associative } 

(Tjfe • (3) -h 

< {A; forward } 

(7 • k) • h 

= { • associative } 

7 • (k • h) 



( backward case) 

7 • (k • h) 

= { • associative } 

(7 • k) • h 

< { k backward } 

(Tfc • /?) • h 

= { ■ associative } 

Tfc -(/3-h) 

< { h backward and (10) } 

T fc • T h • a 

= { T functor } 

T(fc • h) • a 

□ 



Such a split of a coalgebra morphism, witnessing a bisimulation equation, into 
two conditions, makes it possible to capture separately transition preservation 
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and reflection. To prove the next result, however, it is necessary to impose an 
extra condition on the refinement preorder < expressing its compatibility with 
Gt: for all x £ X and X\,X 2 G TX, 



x Gj X\ A Xi < X 2 => x Gy X 2 (11) 

Lemma 3. Let T be an extended polynomial functor in Set, and a and [3 two 
T -coalgebras as above. Let — > a and — denote the corresponding transition 
relations. A forward (respectively, backward) morphism h : a — * (3 preserves 
(respectively, reflects) such transition relations. 

Proof. Preservation follows from 

u — > a u' 

= { — > definition } 

v! Gt ol u 

=> { Gt definition } 

h v! Gt (T h • a) u 
= { h forward and (11) } 

h u Gt ((3 • h) u 

= { • associative and — > definition } 

h u — h v! 

To establish reflection suppose that h u — ^ v', i.e., v' Gt ((3 • h) u. As h is a 
backward morphism we have (3 • h < T h • a, which, together with requirement 
(11), entails v' Gt (T h • a) u. This implies the existence of a state u' G U such 
that v' = h u' and u! Gt ce u, i.e., u — > a v! . □ 

5 Behaviour Refinement 

The existence of a forward ( backward ) morphism connecting two components 
p and q witnesses a refinement situation whose symmetric closure coincides, as 
expected, with bisimulation. In the sequel we will restrict ourselves to forward 
refinement 3 and define behaviour refinement as the existence of a forward mor- 
phism up to bisimulation. Formally, 

Definition 3 Component p is a behaviour refinement of q, written q<lp, if there 
exist components r and s such that p ~ r, q ~ s and a (seed preserving) forward 
morphism from r to s. 

The exact meaning of a refinement assertion qfl^p depends, of course, on the 
concrete refinement preorder < adopted. Let us consider a few possibilities. 

3 A similar study can be made about backward refinement, although the underlying 
intuition seems less familiar. 
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— T - structural inclusion, defined by x < y iff V e g Tx . e €t y, seems inadequate 

because the transition relation preserved by a forward morphism is not — 
but simply — > p , and, therefore, blind to the outputs produced. This suggests 
an additional requirement on refinement preorders for Cp components: their 
definition on a constant functor AT is equality on set K , i.e., x <k y iff 
x =k y so that transitions with different O-labels could not be related. 

— Building on this idea, we arrive to a first (good) example: 



x C, d y iff x = y 
x C K y iff x= K y 

xC TlXl - 2 y iff ni X C Tl m y A tt 2 X Cj 2 n 2 y 



x c Ti +t 2 y iff 



x = i\ x' Ay = i\ y' x' C Tl y' 

x = i 2 x' Ay = i 2 y' x' C Ta y' 



x C Tj k y iff Vfegif. x k C T y k 
X CpT y iff Gy ^ — T e 



A forward refinement of non deterministic components based on C T captures 
the classical notion of nondeterminism reduction. 

— However, this preorder can be tuned to more specific cases. For example, 
the following ‘failure forcing’ variant - C^, where E stands for ‘emptyset’ 
- guarantees that the concrete component fails no more than the abstract 
one. It is defined as C T by replacing the clause for the powerset functor by 

x cf T y iff (x = 0 y = 0) A V e6a; 3 e ev . e C T e' 

— Relation C T is inadequate for partial components: refinement would collapse 
into bisimilarity, instead of entailing increasing definition in the implementa- 
tion. An alternative is relation (F standing for ‘failure’) which replaces 
the sum clause in C T by 

! x = i\ x' Ay = i\ y' => x' C T y' 
x = t 2 * y — L 2 * 

y = 1 2 * => true 

To illustrate behaviour refinement, consider the lossy buffer LBuff introduced 
in section 2, and a deterministic buffered channel Buff specified as a coalgebra 
M* — > (M* x (1 + M)) m+1 with nil as the initial state, and dynamics given 
by 

«Buff (w, put m) = (m:u,L i *) 

UBuff (u, pick) = (tail u, l 2 (head u)) 

To establish LBuff < Buff it is required first to embed the latter into the space of 
non-deterministic systems. This is achieved by a (natural) transformation from 
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(Id X O) 1 to P(\d x O) 1 canonically extending function sing a; = {x} which is 
a monad morphism from the identity to the powerset monads - the behaviour 
models underlying Buff and LBuff, respectively. Then, it is immediate to verify 
that the identity function on state space M* is a forward morphism, with respect 
to the first preorder given above, i.e., 

(id X O) • CtBuff Q OLBuff 

Another behaviour refinements of LBuff would arise by choosing different 
strategies for delivering elements from the buffer. Here are some possibilities, 
each of them is witnessed by a forward morphism: 

— the queuing strategy, leading to the specification Buff as above; 

— the stack strategy (LIFO deliver); 

— the priority strategy (in which elements carry some probability information); 

— the lift strategy (a linear order on the elements is served in alternating 

increasing and decreasing order) . 

In the priority strategy, for example, elements are labelled with a ‘show-up’ 
probability, introducing an elementary form of probabilistic nondeterminism. As 
detailed in [3], the corresponding behaviour monad is generated by a monoid 
M = ([0, 1], min, x) with the additional requirement that for each m £ M, 
^(Vtt z) m — 1- ‘Probabilistic’ components can be embedded into the space of 
‘plain nondeterministic’ ones where behaviour refinement, wrt C T , is discussed. 

6 Simulations 

In this section we prove that behaviour refinement, as characterized above, can 
be established by a simulation relation R C U p x U q on the state spaces of the 
‘concrete’ (p) and the ‘abstract’ (q) components. Again, the notion of a simula- 
tion depends on the adopted refinement preorder <. To proceed in a generic way, 
we adopt an equally generic definition of simulation due to Jacobs and Hughes 
in [9]: 

Definition 4 Given a Set endofunctor T and a refinement preorder <, a lax re- 
lation lifting is an operation Rel<( T) mapping relation R to < o Rel(T)(R) o <, 
where Rel(T)(R) is the lifting of R to T (defined, as usual, as the T -image of 
inclusion (rq, rft) '■ R — > U xV, i.e., (Tn, T/q) : TR — > T U x TV ). 

Given T -coalgebras a and ft, a simulation is a Rel<(T)~ coalgebra over a and 
ft, i.e., a relation R such that, for all u £ JJ,v £ V, (u,v) £ R => (au,ftv) £ 
Rel<(T)(R). 

In order to prove that simulations are a sound proof technique to establish 
behaviour refinement we consider separately functional and non functional simu- 
lations. In any case, however, simulations are assumed to be left total relations 4 
as we do not consider partial refinements. 

4 A relation R C U x V is functional if every u £ U is related to at most one v £ V 
and left total if for all u £ U, there exists some v £ V such that (u, v) £ R. 
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Lemma 4. Let p and q be T -components over state spaces U and V, respectively. 
For a given refinement preorder <, if there exists a simulation R C U xV which 
is both functional and left, total, then p is a (forward) refinement of q. 

Proof. By assumption, simulation R is the graph of a function. Now, define a 
forward morphism h:U—>Vashu = v iff (u,v) G R. Because R is a 
simulation, for every pair (u, v) G R, there should exist x € T U, y G TV, such 
that au <tc/ x, y <tv Pv, and (x,y) G Rel(T)(R), i.e., y = T h(x). By (10) and 
a u <ju x we get T h(au) <tv T hfx), and thus T h(au) <tv Pv. Since R is 
left total, h is defined for all u G U , making the following diagram to commute: 



hu = v 
0 



T h 



au(<jirau) — ► T h(au)<jv P '1 



□ 



Consider, now, the non-functional case ( e.g . whenever two bisimilar but not equal 
abstract states are represented by a single concrete state). To prove soundness 
in this case, the state space of the ‘concrete’ component p is artificially inflated 
with an auxiliary state space such that a forward morphism can be found. 

Definition 5 Given a coalgebra ( U,a : U — » TU) and a set W, define the 
extension of a toW as any coalgebra a over U = UxW such that Tn\oa = ao7Ti . 

Clearly this auxiliary state space does not interfere with the behaviour of a: tt\ 
being a coalgebra morphism, the two coalgebras are bisimilar. 

Given components p and q and a non-functional simulation R an auxiliary 
coalgebra p can be defined taking R as the state space (which, because R is 
left total, is just an extension of p in the sense of the definition above) and the 
rule (u',v') Gt a(u,v) iff u! Gt a p u A v' Gt a q v as its dynamics. With this 
construction we prove that 

Lemma 5. (Soundness) To prove q < p it is sufficient to exhibit a left, total 
simulation R relating components p and q. 

Proof. If R is functional the result follows from lemma 4. Otherwise construct p 
as above: clearly p is bisimilar to p and the graph of projection tt 2 from its state 
space to V defines a simulation between p and q. By definition, p ~ p and the 
existence of a (seed-preserving) forward morphism from p to q entails q < p. □ 

Finally notice that, although < is transitive, it is not always the case that 
simulations are closed under (relational) composition. This would be a conse- 
quence of Rel<(T) preserving composition, but, in general, only the following 
weaker result holds: 



Lemma 6. Any refinement, preorder < verifies 

Rel<(T)(R o S) C Rel<(T)(R) o Rel<(T)(S) and =tu C Rel< (T)(=y) 
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Proof. For the first statement note that (u,w) € Rel<(T)(R o S) equivales 

3 u' , w' .(it <v! A ( u w 1 ) £ Rel(T)(R o S) A w' < w) 

{because Rel(T)(R o S) = f?ef(T)(i?) o i?eZ(T)(5)} 

<=>3 u' , w' .(it <u' A (3 v 1 .((u r , v') £ Rel(T)(R) A (t/, «/) € i?e?(T)(S))) Aw' < w) 
<=>3u', w' , v'.(u < v! A (t/, i/) £ Rel(T)(R) A (i/, in 7 ) £ Rel(T)(S) A w' < w) 
{introducing v = v'} 

=>3u', w' , v, v'.(u < u! A (t/, u 7 ) £ Rel(T)(R) /\v' < v)A 
(v < v' A (?/, ui / ) £ i?eZ(T)(5) Aw' < w) 

=>3v.(u,v) £ Rel<(T)(R) A (v,w) £ Rel<(T)(S) 
o(u,w) £ Rel<(T)(R) o Rel<(T)(S) 

Then consider 

=TU Q —TU 

= <TU ° =TU ° <TU = <TU °Rel(T)(=u)° <TU = Rel<(T)(=u) 

□ 



7 Discussion and Future Work 

In this paper, two levels of refinement for (state-based) components have been 
introduced. In particular, the notion of behavioural refinement parametric on a 
model of behaviour captured by a strong monad B is, to the best of our knowl- 
edge, new. It is generic enough to capture a number of situations, depending on 
both B and the refinement preorder adopted. Nondeterminism reduction is just 
one possibility among many others. Also note that Poll’s notion of behavioural 
subtyping in [13], at the model level, emerges as a particular instantiation. 

As mentioned in the introduction, the main motivation underlying this work 
is the development of inequational laws in the context of the component calculus 
proposed in [3] . Even though there is not enough space in this paper to introduce 
the derived laws, let us take a brief glimpse. As a first example consider equation 

r !; n ~p;Ho n (12) 

which does not hold for non trivial behaviour models. In fact the Cp lifting of 
the final arrow (as the lifting of any other function) cannot fail, whereas the 
the right hand side may fail (whenever p does). Function ! : U p x 1 — > 1 is, 
however, a forward morphism, with respect to for partial components, or 
to both C T and for non deterministic ones. For this last case, note that 
® r !o n '- = A i £ I. {*}, whereas B(! x id) 7 • d p .n 0 -i (u,*) equals 



Ai £ I . 



{*} iff (a p u) (i) ± 0 

0 iff (Tip u) (i) = 0 
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Therefore, r !/ n < p ; r !o n - Similarly, the cancellation law for parallel composi- 
tion IEI, which involves a split- like construction for components (which, differ- 
ently from the split of functions [4], is not an universal arrow), is, in general, a 
refinement result: 

p < (p, q ) ; r *r (13) 

witnessed by projection 7Ti : U p x U q x 1 — * U p as a forward morphism. Yet 
another example is given by the (pseudo) naturality of r A n , where A is the 
diagonal function, which could be written as 

r A n ;(pElp) < p; r A n (14) 

Finally, monotonicity of < with respect to both pipeline composition and the 
tensor products can be proved by defining a simulation in terms of the argument 
simulations: if g<lp and f <r are witnessed by R\ and R 2 , respectively, refinement 
qOt < p □ r, with □ standing for or ffl is witnessed by simulation R = 

{(( u p ,u r ), (u g ,u t )) I (u p ,U q ) G i?i A (u r ,u t ) G R 2 }- 

Currently we are working on the full development of the refinement calculus 
and, in particular, in its application to the proof of consistency between static 
and dynamic diagrams in Uml in the context of [12]. Whether this approach 
scales up to be useful in the classification and transformation of software ar- 
chitectures [1] remains a research question. Further comparison with refinement 
theories in both process algebra (as in, e.g ., [5]) and state-based systems (for 
example in [6]) is also in order. 
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Abstract. Specification Diagrams (SD) [19] are a graphical notation for 
specifying the message passing behavior of open distributed object sys- 
tems. SDs facilitate specification of system behaviors at various levels of 
abstraction, ranging from high-level specifications to concrete diagrams 
with low-level implementation details. We investigate the theory of may 
testing equivalence [15] on SDs, which is a notion of process equivalence 
that is useful for relating diagrams at different levels of abstraction. We 
present a semantic characterization of the may equivalence on SDs which 
provides a powerful technique to relate abstract specifications and refined 
implementations. We also describe our prototypical implementation of 
SDs and of a procedure that exploits the characterization of may testing 
to establish equivalences between finitary diagrams (without recursion). 

Keywords: Graphical specification languages, 7r-calculus, may testing, 
trace equivalence, rewriting logic. 



1 Introduction 

Smith and Talcott introduced Specification Diagrams (SD) [19] as a graphical 
notation for specifying message passing behaviors of open distributed object 
systems. SDs not only have an intuitive appeal as other graphical specification 
languages such as UML [18] and MSC [17], but also have a formal underpinning 
which makes them amenable to rigorous analysis. SDs draw upon concepts from 
various formalisms for concurrency; they allow dynamic name generation and 
name passing as in the 7r-calculus [14], they have asynchronous communication 
and enforce the locality discipline on use of names as in concurrent object- 
based models such as the Actor model [1], they are equipped with imperative 
notions such as variables, environments, and assignments, and they also incor- 
porate logical features such as assertions and constrains which are appropriate 
for specification languages. 

The language of SDs is designed to be useful at various stages of the soft- 
ware cycle. In the initial stages, one can abstractly express the desired system 
behavior and its properties without having to switch to another logic, and then 
progressively refine the abstract specifications into concrete diagrams with im- 
plementation details. An important task to be accomplished in this process is to 
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be able to formally prove that a refined diagram is indeed a correct implemen- 
tation of an abstract specification. The framework of may testing [15] is useful 
for formalizing such a semantic correspondence between diagrams. It is known 
that may testing is useful for reasoning about safety properties of implementa- 
tions; specifically, it formalizes the criteria for a refined diagram to be a safe 
implementation of an abstract specification. 

Relating diagrams according to may testing is in general a difficult task. In 
this paper, we present a characterization of may testing on SDs that provides a 
powerful technique for relating diagrams. We also present an executable imple- 
mentation of SDs by modeling the language as a theory in rewriting logic [12]. 
The Maude tool [5] which supports specifications in rewriting logic can then be 
used to execute diagrams. Finally, we describe the implementation in Maude of 
a procedure that exploits the characterization of may testing to relate Unitary 
diagrams that do not involve recursion. 

SDs are more of a specification language rather than a programming lan- 
guage in that not every SD is executable. For instance SDs are equipped with 
the constraint construct that is analogous to Dijkstra’s assume predicate [7]. 
A constrain specifies a predicate that should hold during a computation; failure 
of the predicate indicates that such a computation never happens, i.e the entire 
computation “is cancelled in between the computation” as though it never hap- 
pened. It is clear that the constrain construct is not implementable in general. 
SDs are also equipped with certain fairness notions that are not implementable 
[20] (see the end of Section 3). In this paper, we will consider only the executable 
fragment of SDs; in particular we discard the constrain construct and the fair- 
ness conditions. Although the language we consider is only a fragment of Smith 
and Talcott’s language, from now on we will refer to it as the language of SDs. 

A central theme of our work is that we present SDs as an extension of asyn- 
chronous 7r-calculus [3, 9] with certain imperative and logical constructs. We will 
exploit this connection both to obtain a characterization of may testing and an 
executable implementation of SDs. Specifically, we will adapt our characteriza- 
tion of may testing for asynchronous 7r-calculus with locality [24] to obtain a 
characterization of may testing on SDs. Similarly, we will extend our implemen- 
tation of asynchronous 7r-calculus described in [22] to obtain an implementation 
of SDs. In summary, this paper has three main contributions. It presents SDs as 
an extension of asynchronous 7r-calculus and exploits this connection to obtain 
both a characterization of may testing and an implementation of SDs. 

Following is the layout of the rest of this paper. In Sections 2 and 3, we present 
SDs as an extension of asynchronous 7r-calculus. In Section 4, we instantiate the 
framework of may testing on SDs and present an alternate characterization of 
it. In Section 5, we describe our implementation of SDs in the Maude tool. We 
conclude the paper in Section 6 with comments on possible directions of future 
work. 

2 Specification Diagram Syntax 

We assume a set of values Val, which is not specified completely, but is assumed 
to include booleans and an infinite set of names Af. We assume an infinite set 
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of variables Var, which can take on values from Val. The sets Var and Val are 
assumed to be disjoint. We let u,v,w range over Val, a,b,c over Af, p,f over 
sets of names, and x, y, z over Var. An environment is a partial function from 
Var to Val that is defined for only finitely many variables. We let 7 range over 
environments. We denote an environment as a subset of Var x Val in the usual 
way. We assume a set of operations on Val that is not specified completely, 
but is assumed to contain the equality operator =, and the boolean operators 
— 1, V and A. We also assume a function n(j on values such that n(v) is the 
set of all names that are used in constructing the (possibly composite) value v; 
we assume that this set is always finite. We lift the function n(-) from Val to 
environments in the expected way. We let e, f, g range over expressions and <fi over 
boolean expressions. Expressions can contain free variables, and are evaluated in 
an environment that assigns values to these variables. We assume an evaluation 
function eval(e,7) that evaluates an expression e in an environment 7 that assigns 
values to all free variables in e. From now on, we use the words diagrams and 
processes interchangeably. 

SDs are defined by the following context-free grammar. We assume a set of 
process variables PrVar that is disjoint from Var and Val, and let X, Y, Z, . . . 
range over it. 

D := 0 | ae \ a(x).D \ D\\D 2 | ( va)D | rec X.D \ X (asynch 7 r) 

| Di\D 2 I D\®D 2 I fork(D) (control) 

| { I 7 : | x := e (imperative) 

| pick(a;).-D | wait(^) (logical) 



Following is an informal description of each of these constructs - (i) 0 (nil): 
Trivial behavior that does nothing, (ii) ae (output): Send an asynchronous mes- 
sage to a with the result of evaluating e as the content. The name a is said to 
be the subject of the output, (iii) a(x).D (input): Receive an input u at a and 
continue as D{u/xj (substitution). All occurrences of x in D are bound by the 
input argument. The name a is said to be the subject of the input, (iv) Di\D 2 
(parallel composition): Execute D\ and D 2 parallely (possibly involving inter- 
actions between the two), (v) (va)D (restriction): Privatize the name a to D. 
All occurrences of a in D are bound by the restriction, (vi) recX.D (recursion): 
Behave as D{recX.D/ X} . All occurrences of X in D are bound by the recursion 
operator, (vii) Dp,D 2 (sequential composition): Execute D\, and then execute 
D 2 . (viii) D\ © D 2 (choice): Execute exactly one of D\ and D 2 . (ix) fork(D) 
(fork): Make a copy of the current environment and execute D with this copy 
as its environment. D is to be executed concurrently with the (parent) diagram 
performing this fork. Specifically, note that the forked diagram and the parent 
diagram do not share their environments, (x) { I7 : D\} (scope): Execute D in the 
environment 7. (xi) x := e (assignment): Assign to x the result of evaluating e. 
(xii) pick(x).D (pick): Pick any value v such that n(v) contains only the names 
that are currently in use, and execute D{v/x}. In particular, this construct does 
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not generate fresh names. All occurrences of x in D are bound by the pick, (xiii) 
wait((f>) (wait): Wait until the environment is such that (j> evaluates to true. 

The reader is referred to [20] for a graphical representation of these constructs 
and a description of how many other constructs such as conditionals and loops 
can be encoded using the these constructs. 

SDs impose the discipline of locality in the use of names, where the recipient 
of a name communicated in a message is only allowed to use the name for 
sending messages; in particular, the recipient does not have the capability to 
listen to messages targeted to the received name. Locality is a common feature 
of concurrent object-based systems and it was first formally investigated in the 
setting of 7r-calculus by Merro and Sangiorgi [11]. The SD syntax automatically 
enforces the locality discipline since an input subject is always a name (constant) 
and names can only be bound by a restriction. In particular, an input subject 
cannot be bound by the argument of another (enclosing) input, and hence the 
recepient cannot listen to messages targeted to the names it receives. 

In addition to locality, SDs also enforce uniqueness of names. Specifically, let 
rcp(D) be the set of all free names in D that occur as an input subject. This set 
contains all the free names at which D can currently receive a message. For a top- 
level diagram D, the uniqueness property states that no other process besides D 
can receive messages at a name in rcp(D). Therefore, in particular, if D\, D 2 are 
two top-level diagrams, then rcp(Di)r\rcp(D 2 ) = 0. Note that locality guarantees 
that the uniqueness property is an invariant during execution; the set rcp(D) may 
expand during the computation as private names of D are exported in outputs, 
and locality ensures the uniqueness property for these exported names. 

We end this section with a few definitions and notational conventions. As 
usual, we do not distinguish between a-equivalent processes, i.e. processes that 
differ only in the use of bound names, bound variables, or bound process vari- 
ables. The functions fn(-) and bn(-) which return the set of all free names and 
bound names that occur in a process (respectively), are defined as expected. Fur- 
ther, we define n(D) = fn(D) U bn(D). A value substitution is a partial function 
from Var to Val that is defined only for finitely many variables. We write {v /x} 
to denote the (value) substitution that maps Xi to ty and is undefined for all 
other variables, where ay and ty are the i th components of the tuples x and v. We 
write D{v/x} to denote the result of simultaneously substituting all occurrences 
of Xi in D with ty . As usual, substitution is defined only modulo a-equi valence 
with the usual renaming of bound names to avoid captures. Similarly, a process 
substitution is a partial function from PrVar to processes, that is defined only 
for finitely many process variables. The notations {D/X} and D'{D/X} have 
the expected meaning. 



3 Operational Semantics 

We define the SD semantics using a labeled transition system in the SOS style 
introduced by Plotkin [16]. The transition labels are of five kinds. 
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i. t: An internal action. 

ii. (£)av: An input of value v at name a. £ is the set of names in n(v) that are 
fresh with respect to the diagram D performing the input. 

iii. (fffav: An output of value v to name a. f is the set of names in n(v) that are 
private to the diagram performing the output. These names will no longer 
be private to the diagram after the output. 

iv. ( tf)pick(y ): Execution of a pick construct that picks a value v. f is the set of 
all names in n(v) that are private to the diagram performing this action. 

v. (£)fork(D,'y): Execution of a fork construct that forks a diagram D with 
environment 7. £ is the set of all names in n{D) U n( 7) that are private to 
the diagram performing this action. 

The functions fn(-) and bn(-) over actions are defined as expected; in par- 
ticular £ is the set of bound names for the actions above . We let a range ove 
the set of all actions, and define n(a) = fn(a) U bn(a). For environments 71,72, 
we define 7 = 71572 as 7(2:) = 71 (x) if 71 (x) is defined, and 72 (x) otherwise. 

We write 7[x — > ft], where x = Xi x n and u = u\ u n , as a shorthand 

for {(x n ,u n )}; . . . ; {(xi, tti)}; 7. We say that D is trivial if its syntax does not 
contain the input, output, fork, assign, pick, or wait constructs; such a process 
has the same behavior as 0. For £ = {ai, . . . ,a„}, we write {vf)D as an abbre- 
viation for (vaf ) . . . ( va n )D ; note that this notational convention is defined only 
modulo the ordering of the names a±, ... ,a n which in any case is irrelevant. 
The transition system is defined at two levels - an inner level, and an outer 

Ot 

level. The inner level transitions >— » are between pairs consisting of a diagram 
and an environment in which the diagram is executed (see Table 1). The outer 
level transitions are defined between closed diagrams (see Table 2), i.e. 
diagrams in which every variable occurrence is bound by an input, scope or 
pick construct. The main reason for defining transitions at two levels, besides 
accounting for environments, is that the execution of pick and fork constructs 
is context sensitive. For instance, executing a pick can only return a value v 
such that every name in n(v) is currently in use, and the set of names in use 
is determined by the entire top-level diagram that contains the pick construct. 
Similarly, in case of the fork construct, the forked diagram is to be instantiated 
in parallel with entire top-level diagram. Using two types of transitions facilitates 
the definition of a transition system in the SOS style despite the context sensitive 
nature of pick and fork constructs. 

The transitions in Tables 1 and 2 are all defined modulo a-equivalence on 
diagrams, i.e. if D\ and D2 are a-equivalent then D\ and D2 have the same 
transitions, and so do the pairs (£>1,7) and (£>2,7)- The rules INP, OUT, REC, 
BINP, PAR, RES, OPEN and COM are all analogous to the corresponding 
transition rules for asynchronous 7r-calculus [2], The rules PAR, COM and SUM 
have symmetric versions that are not shown. We now elaborate on the rules 
concerned with pick and fork constructs; the others are self-explanatory. 

The transition label of the PICK rule includes the value v that is being 
picked. All the names in n(v) are progressively accounted for by the RES-PICK 
and TOP-PICK rules; these names should either be private or already occur 
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Table 1. Rules for inner level transitions. 



INP a(x).D,'y > — * D{v/x , -y 
OUT He, 7 > — ► 0 , -y eval(e, 7) = v 



REC 



D {vecX . D / X 
r ecX.D, •y 



, -1 

oT 



-* D , • y 
D , 7 



BINP 



D, 7 



D, ■y 






(0<™ d 
{ b )av 






D , ■y 



b 



n(v) \ (/n(D) n( 7 )) 



D i , 7 > — ► D , •y 

PAR L — s bn(a) fn(D 2 ) = 

D l' D 2 >7 >-»• d i\ d 2i'Y 



D , 7 > — » D , 7 

( vb)D , ■y >4 (vb)D , 7 



b / n( 7 ) n(c) 



Dj > 7 






P 1 i 7 -°2 » 7 



(€)<* 



? 1 'D 2 ,7 ~ (^^)(D 1 !D 2 ),7 



D , 7 > — y D , 7 



(€ {b )TTu 

(iyb)D, 7 U- D , 7 



b = a, b n(v), 
b / £,b / n(-y) 



OPEN-FORK 



(£,)fork(D ini ) 

P>, 7 ^ D » 7 b n(£>l) n(7l) 

b / £,b / n( 7) 



( ub)D , 7 > — ► D , 7 



SEQ 1 



£> 1,7 >-» , 7 



D V ,D 2 ,7 >— ► D 1 ;D 2 , / y 



ASSGN x := e, 7 



SUM D 1 D 2 ,-y >—* Di , 7 

fork(D, 7) 

fork(D) , 7 >-► 0,7 



Do , 7 > — * -Do 1 7 

SEQ 2 — — 2 is trivial 

P> 1 ; £>2 > "7 >— * - d 2 > 7 

0, 7[cc v] eval(e, 7) = v 

PICK pick(x).D,7 D{«/x ,7 

WAIT wait(<£), 7 > — > 0 , 7 eval(<£, 7) = true 



£ > ,7li72 D >7l[^ ^]?72 

{1 71 : .72 >_ *■ {l 7 l[® *>] : D 1 , 7 2 



RES-PICK 



U)pick(v) 

D, 7 > — ► D . 



(£ {b )pick(v ) 

(i/b)D, 7 >4 (i/b)D 



«(«) 



free in the top-level diagram. This ensures that every name in n(v) is currently 
in use. The transition label of the FORK rule contains both the diagram that is 
being forked, and the environment in which the forked diagram will be executed. 
The TOP-FORK rule instantiates this diagram along with the environment, in 
parallel with the top-level diagram. This ensures that the newly forked diagram 
executes concurrently with the current diagram, and that the two diagrams do 
not share their environments. Finally, a note on the TOP-OUT rule. This rule 
accounts for asynchrony in message exchanges. A message emitted by the OUT 
rule can either be immediately exported by the TOP rule, or it can be buffered 
by the TOP-OUT rule. Note that the arguments of a buffered message have 
already been evaluated by the OUT rule that created the message. 
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Table 2. Rules for outer level transitions. 



TOP (A0) ~ (£> ,0) a # P^k, 
D -2-> D f ork 



<.Z)fork(D 2 ,'r) 

TOP-FORK (-P i»0) 77 (-°u 0 ) 



Di — KKDRfh : D 2 |}) 



TOP-OUT (tti,0) ^ (0^0) TOP-PICK (jbjj) U ^ J < D ■ W ) n(v) C { U fn(D) 
D i — (i/^)(D 1 |a-u) D — D 



Let C denote the set of all input and output actions; these are the visible 
actions. Note that every top-level transition is labeled with a r or an action 
in C. We let s,r,t range over the set of traces C* . The functions fn(.),bn(.) 
and n(.) are extended to C* the obvious way. We define a complementation 
function on C as (£)xy = (£)xy, (£)xy = (f)xy, and extend this to C* the obvi- 
ous way. The a-equi valence over traces is defined as expected, and a-equi valent 
traces are not distinguished. For example, the traces ( b)ab.ba and (c)ac.ca are 
a-equi valent; we do not distinguish between the bound names b and c. Since 
we work modulo a-equi valence on traces, for convenience we assume the fol- 
lowing normality condition on any trace s we consider if s = Si.a.S 2 then 
(n(si) U/n(a)) ft bn{a.S 2 ) = 0. 

We define the relation => as the reflexive transitive closure of and 

=^=t> as =>-^=>. For s = l.s', we write D Q compactly as D =^=> Q. 

We write the assertion D D 1 for some D ’ , as D =?=>. We define II?] = 
{s | D ==4>}. Not every trace produced by the transition system corresponds to a 

valid computation. For example, we have (ua)(a(x).D\dv\ba) a(x).D\av 
But the message av is not observable due to the locality property of SDs (see 
Section 2); the locality property prevents the recipient of the private name a from 
listening to messages targeted to a. Further, due to the uniqueness property the 
message av in the top-level diagram a(x).D\av is not observable, although we 
have the transition a(x).D\av To account for this, we define for a set of 
names p , the notion of a p-well-formed trace such that only p-well-formed traces 
can be exhibited by a diagram D with rcp(D) = p. 



Definition 1 . We define rcp(p,s) inductively as rcp(p,e) = p, rcp(p, s.(^)av) = 
rcp(p,s), and rcp(p, s.(^)av) = rcp(p,s) U £. We say s is p-well-formed if s = 
S\.(l;)dv.S2 implies a rcp(p, s i). We say s is well-formed if it is %-well-formed. 



For convenience we adopt the following hygiene condition on traces (in ad- 
dition to the normality condition). Whenever we consider a p-well-formed trace 
s, we have p D bn{s) = 0. The following lemma captures the intuition behind 
Definition 1. 



Lemma 1. Let rcp{D 2 ) D p = 0. Then the computation Z?i|I ?2 => can be un- 
zipped into D\ and D 2 ==> such that s is p-well-formed. □ 
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The original definition of SDs by Smith and Talcott [19] also accounts for 
certain fairness conditions. For instance, it is required that every message that 
is sent during the course of a computation is eventually received. Such fairness 
conditions are in general not implementable, making SDs more of a specifica- 
tion language rather than a programming language. For instance, it is in general 
impossible to decide if a diagram can eventually evolve to a state where it can re- 
ceive a certain message. Since our intention is to focus on an executable fragment 
(or variant) of SDs, we drop these fairness conditions. 



4 May Testing on Specification Diagrams 

The may testing equivalence [15] is a notion of process equivalence which is useful 
to relate specifications at different levels of abstraction. It is an instance of the 
general notion of behavioral equivalence where, roughly, two processes are said 
to be equivalent if they are indistinguishable in all contexts of use. Specifically, 
the context consists of an observing process that runs in parallel and interacts 
with the process being tested. The observer can in addition signal a success 
by emitting a special event. The process being tested is said to pass the test 
proposed by the observer if there exists a run in which the observer signals a 
success; note that due to possible non-determinism the observer and the process 
can take one of many possible computation paths. Two process are said to be 
may equivalent if they pass exactly the same set of tests. 

We consider a generalized version of the usual may equivalence, where the 
equivalence is parameterized with a set of names that determines the set of ob- 
servers that can be used to decide the equivalence. We originally introduced this 
generalized notion in the context of asynchronous 7r-calculus with locality [24] . 

Definition 2 (may testing). Observers are diagrams that can emit a special 
message ftp. We let O range over the set of observers. We say D may O if 

D \0 ==>. We say D\ Ep D 2 if for every O with rcp( 0 ) ft p = 0, we have 
D\ may O implies Di may O. We say D\ ~ p D2 if D\ Ep D2 and D2 Ep Di- 

Thus, only observers that do not listen at names in p are used to decide the 
preorder E P ; the larger the parameter p the smaller the observer set that is used 
to decide Ep- 

May testing is known to be useful for reasoning about safety properties of 
concurrent systems. Specifically, by viewing the observer’s success as something 
bad happening, D\ Ep D2 can be interpreted as D\ is a safe implementation of 
the specification D2, because if the specification D 2 is guaranteed to not cause 
anything bad to happen in a given context (that does not listen to names in p), 
then the implementation D\ would also not cause anything bad to happen in 
the same context. 

The universal quantification over contexts in the definition of may testing 
makes it very hard to prove equalities. Specifically, to prove an equivalence, 
one has to consider all possible interactions between the given processes and all 
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Table 3. A preorder relation on traces. 



( drop ) 


Sl.(C)S2 


d 


si.(£)av.S2 


if (C)S2 ^ ± 


(delay) 


si.(C)(a.or’.S2) 


d 


s\.(tf)av.a.S 2 


if (£)(a.av.S2) ^ T 


( annihilate ) 


Sl.(£)S2 


d 


si.(()av.av.S 2 


if (0*2 / T 



possible observers. The typical approach to circumvent this problem is to find 
an alternate characterization of the equivalence that involves only the process 
being tested [2,4,8]. For SDs, a variant of the trace semantics characterizes the 
parameterized may preorder. In fact, it turns out that the characterization is 
similar to the one for asynchronous 7r-calculus with locality that we presented 
in [24] ; the only difference arising due to the fact that unlike SDs the calculus in 
[24] is not equipped with the mismatch operator on names. The characterization 
in [24] is in turn an adaptation of the characterization for asynchronous 7r- 
calculus [2]. We skip the proofs of all the propositions in this section as they 
are relatively simple extensions of the proofs in [2] and [24] . The main difference 
arises due to the mismatch capability on names in SDs (this capability is absent 
in the formalisms in [2] and [24]), which can be handled using the techniques we 
presented in [23]. 

The trace based characterization of C p over SDs follows. We define a preorder 
A on traces as the reflexive transitive closure of the laws shown in Table 3, where 
(£)• is defined as 



( 0 * 



s if £ = 0 or £ fl fn(s) = 0 

(£ \ {6})si-(0 U {b})av.s 2 if b € f,b € n(v) and there are si,S2,a,£' 

s.t. s = si.(f')av.s 2 and b fL fn(s i) U {a} 
J_ otherwise 



The expression (£)s returns _L, if there is b £ £ such that b is used in s before 
it is received for the first time, i.e. the first free occurrence of b in s is not 
in the argument of an input. Otherwise, the expression binds the first such 
occurrence (in an input in s) of every 6 £ (, and returns the resulting trace. 
The intuition behind the preorder A is that if a process leads an observer to a 
success by exhibiting a trace s, then it can also lead the observer to a success 
by exhibiting any trace r A s. Specifically, inputs are not observable since they 
are asynchronous, and hence they can be dropped, delayed, or annihilated with 
complementary output actions. 

Lemma 2 . If O ==^, then r d s implies O ==£. □ 

Definition 3 . We say [£>2] dp \D 1] if for every p-well-formed trace s, D\ =?=>■ 
implies there is r d s such that D 2 ==>. 



Theorem 1 . £>1 C p D 2 if and only if \D 2 \ d P [£>1]. 



□ 
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So far, we have allowed a given pair of diagrams D\ and D 2 to be com- 
pared with C p for arbitrary p. But if D\ and D 2 are top-level diagrams, due 
to the uniqueness property of names (see Section 2) it makes sense to compare 
D\ and D 2 with C p only if fn{D\),fn{D 2 ) C p. In this case, we can in fact 
strengthen Theorem 1 by dropping the annihilation law. Specifically, for p such 
that fn(Di),fn(D 2 ) C p, we have D\ C p D 2 if and only if for every p- well- formed 
trace s, Di =?=>■ implies D 2 ==>• for some r ^ s using only the laws delay and 
drop. The reason behind this is that since s is p-well-formed and rcp(D) C p, s 
cannot contain complimentary input and output actions. 



5 Executable Specification in Rewriting Logic 

We now specify the language of SDs as a theory in rewriting logic [12]. The 
Maude tool [5] which supports specifications in rewriting logic can then be used 
to execute SDs. We also present a procedure implemented in Maude, that ex- 
ploits Theorem 1 to decide the may preorder relation between finitary diagrams 
(without recursion). To simplify matters we assume that the set of values Val 
only contains names. Extending this to arbitrary value sets will need sophisti- 
cated symbolic techniques [10,25], which is out of the scope of this paper. 

Since we have represented specification diagrams as an extension of asyn- 
chronous 7r-calculus we can smoothly extend the specification of asynchronous 
7r-calculus in rewriting logic that we introduced in [22] to obtain an executable 
specification of SDs. The main idea behind specifying SDs in rewriting logic is 
to represent an (inner or outer) transition rule of form 

Pi -> Ql ■■■ Pn^Qn 
Po — » Qo 

as a conditional rewrite rule of the form Pq — > Qo if Pi — » Q 1 A ... A 
P n — ► Q n , where the condition includes rewrites. This was first introduced by 
Verdejo et al. [26] for implementing CCS [13]. Such conditional rules with rewrite 
conditions are executable in version 2.0 of the Maude language and system [5]; 
the rewrite conditions are solved by means of an implicit search process. The 
reader is referred to [5,26] for further details. 

In the Maude specification of the SD syntax that follows, the sorts Chan, 
Var, and PrVar are used to represent names, variables and process variables, 
and the sort Env is used to represent environments. Following are operator dec- 
larations for a few of the SD constructs. 

sorts Chan Var PrVar Env Diag . 

op : Chan Qid Diag -> Diag . op {|_:_|} : Env Diag -> Diag . 

op _ I _ : Diag Diag -> Diag . ops new[_]_ rec[J_ : Qid Diag -> Diag . 

The sort Qid represents quoted identifiers. To manage name and variable 
bindings in specification diagrams, we use CINNI as a calculus for explicit sub- 
stitutions [21] which has been implemented in Maude. CINNI gives a first-order 
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Table 4. The CINNI operations. 



[a := x] 


[shiftup a] 


[shiftdown a] 


[lift a S] 


a{ 0 } 1— > x 
a{l} 1 — * a{ 0 } 

a{n+l} 1 — * a{n} 
b{m} 1— > b{m} 


a{ 0 } 1— > a{l} 
a{l} 1 * a{ 2 } 

a{n} 1 — * a{n+l} 
b{m} 1— > b{m} 


a{ 0 } 1— > a{ 0 } 
a{l} 1— > a{ 0 } 

a{n+l} 1 — * a{n} 
b{m} 1— > b{m} 


a{ 0 } 1 — * [shiftup a] (S a{ 0 }) 
a{l} 1 — * [shiftup a] (S a{l}) 

a{n} 1— > [shiftup a] (S a{n}) 
b{m} 1— > [shiftup a] (S b{m}) 



representation of terms with bindings and capture-free substitutions, instead of 
going to the metalevel to handle identifiers and bindings. The main idea in such 
a representation is to keep the bound identifier inside the binders as it is, but 
to replace its use by the identifier followed by an index which is a count of the 
number of binders with the same identifier it jumps before it reaches the place 
of use. This combines the best of the approaches based on standard variables 
and de Bruijn indices [ 6 ]. Following this idea, we define terms of sorts Chan, 
Var and PrVar as indexed identifiers as follows. 

op _{_} : Qid Nat -> Chan . op _{_} : Qid Nat -> Var . 

op _{_} : Qid Nat -> PrVar . 

Note that the operator is (adlroc) overloaded. Following are the con- 

structors for environments. 

op emptyEnv : -> Env . op ( ) : Var Chan -> Env . 

op _ ; _ : Env Env -> Env . eq { I emptyEnv : D I } = D . 

eq {|(X CX) ; E : D|> = {|E : -C I (X CX) : D |> 1} . 

As a result of the equations above, from now on we can assume that the 

environment 7 in {(7 : D|} is of form ( x a). For name substitutions we introduce 
the sort ChanSubst along with the following operations. The intuitive meaning 
of these operations is described in Table 4 (see [21] for more details). 

op [_:=_] : Qid Chan -> ChanSubst . op [shiftdown_] : Qid -> ChanSubst . 

op [shiftup_] : Qid -> ChanSubst . 
op [lift ] : Qid ChanSubst -> ChanSubst . 

We introduce the sort PrSubst for process substitutions, along with similar 
operations as above. Using these, explicit substitutions for SDs can be defined 
equationally. Following are some interesting equations. Note how the substitution 
is lifted as it moves across a binder. 

Var NS : ChanSubst . Var PS : PrSubst . 

eq NS (CX(Y) . D ) = (NS CX) (Y) . ([lift Y NS] D) . 

eq NS (D1 I D2) = (NS Dl) I (NS D2) . 

eq NS (-C I (X CX) : D I > = -C I (X (NS CX)) : [lift X NS] D I } . 

We now describe the specification of the transition system. As mentioned 
earlier, the transition rules are represented as conditional rewrite rules with the 
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premises as conditions of the rule. Since rewrites do not have labels unlike the 
labeled transitions, we make the label a part of the resulting term; thus these 
rewrites are of the form P =>• {a}Q. 

A problem to overcome in giving an executable specification of the transition 
system is that the transitions of a term can be infinitely branching because of 
the INP and OPEN rules. In case of the INP rule, there is one branch for every 
possible name that can be received in the input (recall that we have assumed 
names to be the only values). In case of the OPEN rule, there is one branch for 
every name that is chosen to denote the private channel that is being emitted 
(recall that the transition rules are defined only modulo a-equivalence). 

To overcome this problem, we define transitions relative to an execution 
environment 1 . The environment is represented abstractly as a set of free names 
CS that it may use while interacting with the process, and both the inner and 
outer level transitions are modeled as rewrite rules over terms of the form [CS] 
P. The set CS expands during bound input and output interactions when private 
names are exchanged between the process and its environment. The infinite 
branching due to the INP rule is avoided by allowing only the names in CS to 
be received in free inputs. Since CS is assumed to contain all the free names in 
the environment, an input argument that is not in CS would be a private name 
of the environment. Now, since the identifier chosen to denote the fresh name is 
irrelevant, all bound input transitions can be identified to a single input. With 
these simplifications, the number of input transitions of a term becomes finite. 
Similarly, in the OPEN rule, since the identifier chosen to denote the private 
name emitted is irrelevant, instances of the rule that differ only in the chosen 
name are not distinguished. 

Following is the specification of a few of the inner level transitions (see Ta- 
ble 1). 

sorts Action VisAction VisActionType EnvProc TraceProc . 
subsort VisAction < Action . subsort EnvProc < TraceProc . 

ops i o : -> VisActionType . 

op f : VisActionType Chan Chan -> VisAction . 
op b : VisActionType Chan Qid -> VisAction . 
op [_]<_,_> : ChanSet Diag Env -> EnvProc . 
op {_}_ : Action TraceProc -> TraceProc [frozen] . 

rl [INP] : [CY CS] < CX(X) . D , E > => 

{f(i,CX,CY)> [CY CS] < [X := CY] D , E > . 
crl [BINP] : [CS] < D, E > => 

{ [shiftdown ’U] b(i,CX,’U)} [’U{0> [shiftup ’U] CS] < D1 , El > 
if (not flag in CS) /\ CS1 := flag ’U{0> [shiftup ’U] CS /\ 
[CS1] < [shiftup ’U] D , [shiftup ’U] E > => 

{f (i,CX, ’U{0»> [CS1] < D1 , El > . 

1 We have overloaded the word environment. So far we have used it to denote variable 
bindings. We now also use it to refer to the external process with which the process 
under consideration is interacting. It should be clear from the context as to which 
of these we mean. 
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crl [OPEN] : [CS] <new [X] D , E> => 

{ [shiftdown X] b(o,CY,X)> [X{0> CS1] <D1 , El> 

if CS1 := [shiftup X] CS /\ E2 := [shiftup X] E /\ 

[CS1] <D,E2> => {f (o,CY,X{0})} [CS1] <D1,E1> /\ X{0> =/= CY . 

We have shown the constructors for only the sort VisAction that represents 
visible actions, i.e input and output actions. Since names are assumed to be the 
only values, these actions are of form (b)ab or (&)a&, where the metavariable b 
ranges over {0, {b}}. The operators f and b are used to construct free and bound 
actions respectively. Name substitutions on actions are defined equationally as 
expected. The implementation of the INP , BINP and OPEN rules is similar to that 
of the corresponding rules for asynchronous 7r-calculus [22]. We explain only the 
BINP rule in detail, and refer the reader to [22] for further details. 

In the BINP rule, since the identifier chosen to denote the bound argument is 
irrelevant, we use the constant ’U for all bound inputs, and thus ’U{0} denotes 
the fresh name received. Note that in contrast to the BINP rule of Table 1, we 
do not check if ’ U{0} is in the free names of the process performing the input or 
its variable bindings, and instead we shift up the channel indices appropriately 
in CS, D, and E in the rightlrand side and condition of the rule. This is justified 
because the transition target is within the scope of the bound name in the input 
action. Note also that the channel CX in the action is shifted down because it is 
now out of the scope of the bound argument. The set CS is expanded by adding 
the received channel ’U{0} to it. Finally, we use a special constant flag of sort 
Chan, to ensure termination. The constant flag is used to prevent the BINP 
rule from being fired again while evaluating the condition. Without this check, 
we will have a non-terminating execution in which the BINP rule is repeatedly 
fired. 

Following is the implementation of one of the outer level transitions (see 
Table 2). 

sorts EnvDiag TraceDiag . subsort EnvDiag < TraceDiag . 
ops tau bpick : -> Action . op fpick : Chan -> Action . 
op [_] _ : ChanSet Diag -> EnvDiag . 
op {_}_ : Action TraceDiag -> TraceDiag [frozen] . 
crl [TOP-PICK] : [CS] D => {tau} [CS1] D1 

if [CS] < D , emptyEnv > => {A} [CS1] < D1 , emptyEnv > /\ 
(A == bpick \/ (A == pick(CX) /\ CX in freenames(D) ) ) . 

The constant bpick is used to represent a pick action that picks a bound 
name, while fpick is used to denote an action that picks a free name. Note that 
the operator {_}_ above is declared frozen. This forbids rewriting of its argu- 
ments; otherwise rewrites can be applied to any subterm. We use the frozen 
attribute because otherwise for a recursive process D the term [CS] D may 
have a non-terminating rewrite sequence [CS]D => { A 1 } [CS]D1 => {A 1 } { A2} 
[CS] D2 => .... But since {_}_ is declared frozen a term [CS] D can be rewrit- 
ten only once. To compute all possible successors of a term, we explicitly generate 
the transitive closure of one step transitions as follows (the dummy operator [_] 
declared below is used to prevent infinite loops). 
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sort TEnvDiag . 

op [_] : EnvDiag -> TEnvDiag [frozen] . 

crl [reflx] : [ P ] => {A} Q if P => {A} Q . 

crl [trans] : [ P ] => {A} R if P => {A} Q /\ [ Q ] => R . 

Now, the set of all traces exhibited by [CS] D can be computed by finding all 
the one step successors of [ [CS] D] . The traces appear (with tau actions) as the 
prefix of these one step successors. Of course, there can be infinitely many one 
step successors if D is recursive, but using the meta- level facilities of Maude we 
can compute only as many of them as needed. To represent traces, we introduce 
the sort Trace as follows. 

subsort VisAction < Trace . 

op epsilon : -> Trace . op [_] : Trace -> TTrace . 

op : Trace Trace -> Trace [assoc id: epsilon] . 

ceq [TR1 . b(ID,CX,Y) . TR2] = 

[TR1 . b(I0,CX,’U) . [Y := ’U{0}] [shiftup ’U] TR2] 

if Y =/= ’U . 

The equation above defines a-equivalence on traces the expected way. The 
function rwf which checks if a trace is p-well-formed can be defined along the 
lines of Definition 1. 

We encode the relation -< of Table 3 as rewrite rules on terms of sort TTrace. 
Specifically r < s if cond is encoded as s => r if cond. 

rl [Delay] : [ ( TR1 . f(i,CX,CY) . b(ID,CU,V) . TR2 ) ] => 

[ ( TR1 . b(I0,CU,V) . ([shiftup V] f(i, CX , CY) ) . TR2 ) ] . 

crl [Delay] : [ ( TR1 . b(i,CX,Y) . f(ID,CU,CV) . TR2 ) ] => 

[ ( TR1 . bind(Y , f(ID,CU,CV) . f (i , CX, Y{0}) . TR2) ) ] 

if bind(Y , f(IQ,CU,CV) . f (i ,CX, Y{0}) . TR2) =/= bot . 

The operator bind implements the function ( y )• on traces. Note that in the 
first Delay rule, the channel indices of the free input action are shifted up when 
it is delayed across a bound action, since it gets into the scope of the bound 
argument. Similarly, in the second Delay rule, when the bound input action is 
delayed across a free input/output action, the channel indices of the free action 
will be shifted down by the bind operation. The other two subcases of the Delay 
rule, namely, where a free input is to be delayed across a free input or output, 
and where a bound input is to be delayed across a bound input or output, are 
not shown as they are similar. 

To decide D\ C p D 2 for finitary diagrams D±,D 2 without recursion, we 
exploit the alternate characterization of C p given by Theorem 1. But a problem 
with this approach is that finiteness of D only implies that the length of traces in 
|T>] is bounded, but the number of traces in \D\ can be infinite (even modulo a- 
equivalence) because the INP rule is infinitely branching. To avoid the problem 
of having to compare infinite sets, we observe that 

\D 2 ] 3 P \Di\ if and only if \D 2 ]j nCDx.Ds) fjp [Di\f n(D 1} D 2 ), 

where for a set of traces S we define = {s € S \ fn(s) C £}. Now, since the 
traces in \Di\ and [D 2 ] are finite in length, it follows that the sets of traces 
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\Di]f n (D 1 ,D 2 ) and \D 2 \f n (D 1 ,D 2 ) are finite modulo ct-equi valence. In fact, the 
set of traces generated for [ [fn(Dl ,D2)] Dl] by our implementation, contains 
exactly one representative from each a-equivalence class of [Di]f n ( Dl D2 y 

Given processes D\ and D 2 , we generate the set of all traces (modulo a- 
equivalence) of [[fn(Dl,D2)] Dl] and [[fn(Dl,D2)] D2] using the metalevel 
facilities of Maude. Then for each p-well-formed trace T in \Di\f n ( DltD2 ), we 
compute the reflexive transitive closure of T with respect to the rewrite rules for 
the laws in Table 3. We then use the fact that \D 2 \f n (D 1 ,D 2 ) I Di\fn(D 1 ,D 2 ) if 

and only if for every p- well-formed trace T in |T , i]/n(Di,D 2 ) the closure of T and 
\D 2 \f n (D 1} D 2 ) have a common element. We skip the details of the implementation 
using metalevel facilities of Maude, as they are the same as that for asynchronous 
7r-calculus [22], 

6 Conclusion 

We have presented the executable fragment of SDs as an extension of asyn- 
chronous 7r-calculus. We have exploited this relation to both obtain an imple- 
mentation of SDs, and to develop a theory of may testing for SDs. An interesting 
direction for future work is to investigate the theory of may testing for the entire 
SD language. Features such as fairness conditions and the constraint predicate, 
which we have not considered here, change the characterization of may testing in 
a non-trivial way. Another problem of interest is to extend the implementation 
of may testing for the case where there are other infinite value domains besides 
names, such as integers and lists. This would involve the use of sophisticated 
symbolic techniques to handle these infinite value domains [10,25]. The result- 
ing implementation of may testing over the full fledged SD language with a rich 
value set can be used for reasoning about practical examples; such case studies 
are also a topic of interest. 
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Abstract. CRESS (Chisel Representation Employing Systematic Specification) 
is used for graphical behaviour description, underpinned by formal and imple- 
mentation languages. Plug-in frameworks adapt it for particular application do- 
mains such as Intelligent Networks, Internet Telephony and Interactive Voice 
Response. The CRESS notation and its syntax are explained. The semantics of 
CRESS is discussed with reference to its interpretation in LOTOS. 

Keywords: Graphical Specification, Lotos (Language Of Temporal Ordering 
Specification), SDL (Specification and Description Language), Voice Service 



1 Introduction 

1.1 Background 

Diagrammatic representations abound in science and engineering. For example, soft- 
ware engineering uses flowcharts, entity-relationship diagrams, data-flow diagrams, 
state diagrams, and various UML diagrams. In general, diagrams are valued because 
they give a clear overview of a system. In industry, graphical representations are re- 
garded as more accessible than textual ones (especially for more formal specifications). 

This paper describes the basis of CRESS (Chisel Representation Employing Sys- 
tematic Specification). Although CRESS was inspired by the need to represent voice 
services, it is a general-purpose way to represent behaviour graphically. Cress can 
therefore be used for a variety of other applications. Unlike many diagrammatic forms, 
CRESS is precise in that diagrams are interpreted by an underlying formal model. 
CRESS diagrams can also be translated to implementation languages. CRESS supports: 

- graphical behaviour description, open to non-specialists and industrial engineers 

- a precise interpretation that allows rigorous analysis and development 

- a portable toolset that facilitates specification, implementation, analysis and testing. 

The same service diagrams can be used for multiple purposes. CRESS is neutral with 
respect to the target language. For formal analysis, CRESS diagrams are automatically 
translated to LOTOS (Language Of Temporal Ordering Specification [4]) and to SDL 
(Specification and Description Language [6]). For implementation, CRESS diagrams 
are automatically translated to Perl (for Internet Telephony services) or to VoiceXML 
(for Interactive Voice Response services). 

CRESS was initially based on the industrial notation Chisel developed by BellCore 
[1]. However, CRESS has been considerably extended since its beginnings. For example, 
it now supports the notion of plug-in domains: the vocabulary and concepts required 
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for each application area are defined separately. CRESS has been used in the domains 
of Intelligent Networks, Internet Telephony and Interactive Voice Response. 

Although other papers by the author have described the applications of CRESS, the 
present paper considers the, foundations of CRESS, namely the composition, syntax and 
semantics of CRESS diagrams. The CRESS philosophy focuses on two aspects: 

- The graphical notation is of most interest and value to domain experts such as 
communications engineers. Such users require a convenient and pragmatic way of 
describing services. 

- The rigorous analysis of formal specifications derived from diagrams is of most in- 
terest and value to formalists. Such users require precise expression with the ability 
to reason formally about the specifications. 

The translation from diagrams to specifications is of limited interest to both categories 
of user. Although the paper gives some indication of how translation is achieved, it is 
a secondary issue. In particular, the translation procedure is not formalised though the 
results of the translation are formal. The important point is that specifications generated 
from CRESS are precise and can be reasoned about. 

1.2 Relationship to Other Work 

Diagrammatic notations, e.g. visual programming languages, are common in software 
engineering. However few graphical approaches have a formal basis. Statecharts [3], 
LSCs (Live Sequence Charts [7]), and UML all have graphical representations with a 
formal basis. The following techniques are perhaps closest to CRESS: 

- SDL has a graphical syntax and a formal interpretation. However SDL lacks com- 
position mechanisms that are appropriate for building services. It is a specialised 
notation that needs expert knowledge. SDL also does not have support for specific 
application domains. 

- MSCs (Message Sequence Charts [5]) are higher- level and more straightforward. 
Several authors have given formal meaning to MSCs. Like SDL, MSCs are also 
rather generic and lack composition mechanisms suitable for services. 

- UCMs (Use Case Maps [2]) are useful for high-level descriptions of requirements. 
UCMs have been represented using Lotos and MSCs. However the formalisation 
of UCMs is not complete, and they lack support for specific application domains. 

CRESS aims to circumvent these problems: 

- CRESS accepts plug-in domains that allow it to be readily adapted for use in a 
variety of applications. 

- CRESS supports the needs of voice services, though it is more widely applicable. 
Specific mechanisms are provided in Cress for service composition. 

- CRESS is intended as a front-end for formal representations. That is, CRESS is 
translated into a formal language into order to give it precise meaning. The implied 
semantic model of CRESS is reasonably straightforward, so there can be confidence 
in the equivalence of different formal models. 
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Formally-based language translation has been studied for many decades. [9] is an 
example of the state-of-the-art. Although such approaches might in principle be used for 
CRESS, they would be a side interest. In addition, the scale and challenges of translating 
CRESS to very different target languages cast doubt on the practicability of formally- 
based translation. CRESS includes concurrent, nondeterministic and event-driven be- 
haviour. Cress descriptions may be cyclic and may contain context-sensitive expres- 
sions. All these aspects would be challenging for a formal approach to translator design. 
Even if the problems could be overcome, proving the translation correct would be very 
difficult and time-consuming. The outcome would also be of little benefit for the in- 
tended purposes of CRESS (graphical description and formal analysis). 



1.3 Overview of the Paper 

As motivation for CRESS, section 2 briefly overviews the role of CRESS and how it 
has been applied. Section 3 gives a condensed summary of the CRESS notation. An 
overview is given in section 4 of the syntax and static semantics of diagrams. Section 5 
deals with the semantics of diagrams by considering their interpretation in Lotos. 



2 Cress Application 

2.1 The Role of CRESS 

Why not define system behaviour using some implementation technique used for pro- 
gram development? Such a definition would naturally be rather low-level, language- 
dependent, and possibly platform-dependent. It would be hard to analyse the defini- 
tion rigorously. Historically, this is how communications services were defined. The 
approach suffers from major problems such as incompatibility among vendors, incon- 
sistency among features, lack of portability, and cost of testing. 

A formally-based approach is therefore an obvious choice. Why not then just spec- 
ify behaviour using a selected formal method? There are a number of problems that 
Cress aims to circumvent: 

Acceptability: Formal methods have achieved only limited penetration into industry. 
In general, engineers are not trained in formal methods and are hesitant to use them. 
CRESS exploits the benefits of formal methods ‘behind the scenes’ without forcing 
them on the user. As a graphical notation, CRESS is more accessible to the non- 
specialist. Indeed, CRESS benefits from its origins in Chisel as a notation that can 
be used by all stakeholders in system development. 

Architecture: CRESS provides a framework and vocabulary for specifying applica- 
tions in various domains. CRESS is therefore close to the architectural level at which 
a domain specialist would normally think. If a plain formal language is used, it is 
necessary to describe behaviour in terms of language concepts rather than in terms 
of architectural concepts. This leads to specifications that are low-level (in archi- 
tectural terms) and verbose. 
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Neutrality: CRESS is not oriented towards any particular domain, target language 
or platform. It can therefore act as a front-end for creating formal specifications. 
CRESS diagrams are currently translated into LOTOS and SDL, and could be trans- 
lated into many constructive formal languages. 

Implementation: Formal specifications are usually rather distant from implementa- 
tion. As a result, the effort put into specification is often not exploited when imple- 
mentation takes place - there is a discontinuity in development that risks introduc- 
ing inconsistencies. CRESS is unusual in that the same diagrams can be translated 
into both formal specifications and into implementations (in selected languages). 

So, when is CRESS applicable? In general it can be used to give a constructive 
description of a system that has inputs, outputs, actions and events. That is, CRESS is 
useful for reactive systems. Although CRESS can be used to describe the behaviour of 
an entire system, its specialised capabilities come into their own when the system can 
be considered as a base behaviour (service) modified by optional additional capabilities 
(features). Such a situation is common in voice applications such as telephony, but 
is also common in many other cases. For example, software applications frequently 
have plug-in modules that are used to extend their abilities. CRESS is therefore most 
appropriate for modular systems. 

CRESS cannot be used for non-constructive (e.g. declarative, logical) descriptions. 
Although CRESS descriptions are hierarchical in the sense of diagrams invoking other 
diagrams, CRESS is not able to describe a system at multiple levels of abstraction. 

CRESS scales reasonably well. Since systems are usually described by multiple di- 
agrams, a complex system can be handled as long as its behaviour can be broken down 
into manageable diagrams. When used for verification (proof), CRESS has the same 
characteristics as the formal language in which CRESS is interpreted. In practice, this 
usually places severe limits on what can be verified. When used for validation (testing), 
CRESS is much more practical. As long as tests can be defined fairly independently, a 
complex system can be validated without much regard to scale. 

2.2 Domain Frameworks 

In themselves, CRESS diagrams have no meaning. In fact, CRESS is deliberately open- 
ended as far as applications are concerned. Although CRESS defines a structure for 
diagrams, diagram content is governed by plug-in domains that define the syntax and 
semantics of diagram contents. As will be seen, CRESS has been used in three domains 
with four target languages. 

Some aspects are domain-specific but language-independent. For example, a do- 
main defines the names and parameter types of input signals, output signals, actions 
and event conditions. The sources and destinations are given for signals. To resolve cer- 
tain kinds of composition problems, diagrams may be given priorities that control the 
order in which they are applied. 

Some aspects are both domain- specific and language-specific. A specification ar- 
chitecture gives an outline specification in the chosen target language. This identifies 
the communicating subsystems and the domain-independent data types. When CRESS 
diagrams in this domain are translated to this language, the generated code is embedded 
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in the specification architecture. Most of the generated code deals with behaviour, but 
some of it defines domain- specific data types. 



2.3 Tool Support 

The CRESS toolset is written largely in Perl for portability. About 14,000 lines of code 
in numerous modules are used to support seven main tools. The major CRESS tool re- 
sembles a conventional compiler. However CRESS is unusual in interpreting a graphical 
description. In addition, the possibly cyclic nature of graphs requires special treatment. 

The CRESS lexer reads each diagram and turns it into a directed graph. The CRESS 
parser combines all the graphs into one, and checks the syntax and static semantics 
of the resulting graph. A CRESS code generator for each target language translates 
the graph into this language. These tools are invoked by a preprocessor that is used 
with a specification architecture. This determines the configuration and deployment of 
diagrams, and embeds their translation into the specification framework. 

When CRESS is interpreted in a formal language, verification and validation are ob- 
vious choices. [15] describes how these can be performed. In general, CRESS is open 
to any verification technique that would normally be used with the formal language. 
However, CRESS is accompanied by its culinary counterpart MUSTARD (Multiple-Use 
Scenario Test And Refusal Description) as a practical means of validating behaviour. 
The MUSTARD tool translates validation scenarios into the target language and automat- 
ically checks them against the system specification. This is used to establish confidence 
in the CRESS description, and also to check for incompatibilities among features. 

As far as possible, the toolset is automated so that the user is unaware of it. For 
example, a Lotos user issues a T OPO toolset command to process a given specification. 
This invokes the CRESS toolset, creates a new specification from the CRESS diagrams, 
and uses Mustard to validate it. Similarly, an SDL user clicks on a button in the 
Telelogic Tau toolset to perform comparable actions. 

2.4 Applications of Cress 

The following is a brief overview of CRESS in selected domains. Refer to the cited 
papers for more details. 

IN: The Intelligent Network is an architecture for telephony networks that separates 
call routing (service switching) from call processing (service control). In particu- 
lar, dedicated network elements handle complex services. The IN supports a flexi- 
ble range of services such as Call Forwarding, Call Screening, Credit Card Calling, 
and FreePhone. IN services are complemented by ones that reside in switches (ex- 
changes), e.g. Call Waiting or Conference Calling. The major issues in defining IN 
services are vendor-independence and mutual compatibility. 

CRESS has been used to model a range of typical services from the IN [10, 12]. 
Such descriptions are independent of vendor, platform and language. The CRESS 
descriptions are interpreted in Lotos or SDL, allowing rigorous analysis in isola- 
tion (checking correctness) and in combination (checking mutual compatibility). 
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Internet Telephony: Voice calls can be supported over an Internet-like network. This 
may be the Internet proper, though voice traffic is increasingly being carried over 
private networks that follow Internet standards. H.323 is a well-established set of 
standards for digital telephony. However SIP (Session Initiation Protocol [8]) is 
a simpler and more flexible alternative that is rapidly gaining in popularity. For 
example, SIP is being widely used to replace conventional telephony, and has been 
adopted for the new generation (3G) of mobile telephones. 

CRESS has been used to model SIP and its associated services. In fact, SIP is suffi- 
ciently new that there is not yet a consensus on what a SIP service is. An important 
aspect of the CRESS work has therefore been to define a SIP service architecture 
[1 1-13]. For formal analysis, a range of SIP services has been described in CRESS 
and interpreted in Lotos and SDL. This part of the work has had similar goals to 
the IN study. To gain practical benefits, the same service diagrams are also trans- 
lated into Perl for use with SIP CGI (Common Gateway Interface). 

IVR: Interactive Voice Response systems are used to provide callers with a voice 
interface. Speech recognition allows natural language enquiries, and speech syn- 
thesis gives fixed or generated voice responses. IVR systems are a major growth 
area, largely because of customer dissatisfaction with touch-tone enquiry systems. 
Among competing standards, VoiceXML [ 16] has gained a dominant position. 
CRESS has been used to model VoiceXML and its associated services [12-15]. 
In fact, VoiceXML does not recognise the concepts of service or feature. Part of 
the CRESS work has therefore been to investigate the value of these ideas in an 
IVR setting. For formal analysis, a range of IVR services has been described in 
CRESS and interpreted in LOTOS and SDL. This part of the work has had similar 
goals to the IN study. For practical deployment, the same service diagrams are also 
translated into VoiceXML for deployment in an IVR server. 



3 Cress Notation 

CRESS may appear to define state diagrams. However, state is intentionally implicit in 
CRESS because this allows more abstract descriptions to be given. CRESS has explicit 
support for defining and composing features. Plug-in domains adapt the notation for 
selected application areas. Sample diagrams from the domains mentioned earlier are 
used to illustrate the notation. 

3.1 Diagram Expressions 

CRESS expressions offer the usual logical, arithmetic and comparison operators. String 
and set operators are also supported. Assignment is indicated by ‘<— ’. Since Cress 
acts as a front-end for a variety of target languages, it does not itself define operator 
precedences. Complex expressions are therefore parenthesised as necessary. 



3.2 Diagram Types 

A CRESS diagram is a directed, possibly cyclic, graph. Ultimately, CRESS deals with a 
single diagram. However it is convenient to construct diagrams from smaller pieces. A 
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multi-page diagram, for example, is linked through connectors. More usefully, CRESS 
supports the notion of feature diagrams that extend or modify other diagrams. This is 
especially useful for systems that have a base functionality plus additional capabilities. 
CRESS supports three similar kinds of diagrams: 

Root Diagrams describe the fundamental behaviour of a system. An extract from a 
sample root diagram appears in figure 1 . This describes POTS (Plain Old Telephone 
Service, i.e. an ordinary telephone call). For example the subscriber may go off- 
hook and dial a number, resulting in both telephones ringing. 




C ^obtainab 1 ^ - ^ ^ ^ Null 



Fig. 1. CRESS Root Diagram (Incomplete) for the Plain Old Telephone Service 



Spliced (Cut-and-Paste) Feature Diagrams are applied to matching behaviour in an- 
other diagram. The feature is copied and used to replace the matching behaviour. 
Note that this is a static, syntactic operation. A modified diagram is created by the 
process of composition. A spliced feature has a unique entry node. It has one or 
more exit nodes that indicate how it flows back to the diagram being modified. A 
spliced feature can be used to replace, extend or modify behaviour in the original 
diagram. A sample spliced feature appears in figure 2 that describes the Calling 
Number Delivery feature in Intelligent Networks. This matches node POTS 4 that 
follows node POTS 3 via the Free A B arc. If the called number B has subscribed to 
the CallingNumber feature, the caller’s number A is displayed. The feature contin- 
ues from nodes POTS 5 or POTS 13. 

Template (Macro) Feature Diagrams are similar but are parameterised. The actual 
parameters are determined by pattern matching the triggering node to the template. 
A template feature may have several exit nodes, but only one of these (Finish) con- 
tinues with the original behaviour. A template is instantiated and applied statically 
when diagrams are composed. Sample template features appear in figures 3, 4 and 
5. Figure 3 describes an Intelligent Networks feature to check if the called number 
Q is busy; if so and the callee has subscribed to call forwarding, the call is diverted 
to the selected ForwcirdBusy number. Figure 4 describes an Internet Telephony fea- 
ture that blocks a caller P who appears in the screening list Screenln for callee Q. 
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[Uses /POTS ] 



POTS 3 



Free A B 



-CallingNumDer u y - uawngNumaer B 

7 Display B A 




B 



POTS 5 





POTS 13 



Fig. 2. CRESS Spliced Feature Diagram for Calling Number Delivery 

Figure 5 describes an Interactive Voice Response feature for charity donations. It 
asks the user whether to start again after a request to clear all inputs. Unless the 
user re-confirms clearing, the donation details are submitted to a server. 

It is normally preferable to use template features rather than spliced features. This is 
because the latter often have to repeat large pieces of the matching diagram. If a feature 
loops back to its initial node, this is interpreted as meaning a loop back to the triggering 
node. This allows a chain of features to be triggered by the same node; the instantiated 
features are combined in sequence. 

3.3 Diagram Nodes 

Diagrams contain several kinds of nodes, distinguished by shapes that are arbitrary but 
known: comments, behaviour nodes, labels and rule boxes. 

Comments (parallel lines, figure 1) contain explanatory text. Some diagram editors 
used with CRESS allow hyperlinks to be added as comments, e.g. links to an audio 
commentary, document or figure. 

Behaviour Nodes (ovals) contain behaviours and their parameters. A node is identified 
by a number, optionally followed by one or more symbols to indicate its kind: 

- “>’ (figure 4 nodes 1 and 2) means the node contains input, output signals 
(used if a signal can be sent in both directions) 

- *+’, “=’ (figure 3 node 1, figure 5 node 1) means a template is appended, 

prefixed, substituted (relative to the triggering node) 

- T (figure 5 node 3) means a node will not be matched by a template (used to 
prevent unintended or recursive substitution). 

A behaviour node contains signals (inputs or outputs, figure 1 nodes 1 and 2) or 
actions (like programming language statements, figure 5 node 3). Behaviours may 
carry variables or expressions as parameters (figure 1 node 1, figure 5 node 2) 
Several behaviours may occur in parallel ('|||\ figure 1 node 4). Each behaviour 
may be followed by variable assignments separated by 7 ’. 
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Q <- ForwardBusy Q 

Fig. 3. CRESS Template Feature Diagram for Call Forward on Busy Line 



[Uses /PROXY ) 1 <+ invite P Q 



4 




P In Screenln Q Else 



Response Q P Decline~2^> 








Fig. 4. CRESS Template Feature Diagram for Call Screening 



[ Uses Value restart ] 1- Clear 




Fig. 5. CRESS Template Feature Diagram for Restarting A Charity Donation 



Labels (plain text or ovals) are used as connectors to join parts of a diagram. A source 
label cites the diagram name (optional, meaning the same diagram) and node num- 
ber (figure 2 node POTS 3). A destination label (figure 2 node POTS 5) may define 
variable assignments much as a behaviour node does. 



546 



Kenneth J. Turner 



Special labels are also used. A Start node (figure 3) is the initial one of a graph. 
It is required when a graph is cyclic so the initial node is ambiguous; it is implicit 
when the initial node is well-defined (e.g. figure 1). A Null node (figure 1) does 
nothing. It may be used as a shorthand to join a number of nodes to a number of 
other nodes. A Finish node (figure 3) is used to indicate the exit of a template. In 
fact, labels can be left empty for these special nodes (e.g. a Null label is normally 
omitted, figures 3 and 4). 

Rule Boxes (rounded rectangles) have multiple purposes. They give a variety of rules 
to define variables, diagram interdependencies, assignments, macros, signal trans- 
formations, and configurations. A Uses clause may begin by optionally declaring 
the variables local to a diagram (figure 1). This is optionally followed by 7’ and a 
list of other diagrams that the diagram depends on ( figure 3). For example, a feature 
diagram lists the root (or other) diagrams that it may modify. The explicit depen- 
dencies among diagrams are used to determine the full set of diagrams needed. 

A variable initialisation (not illustrated) assigns a value at the start of behaviour. 
Variables may also be assigned when a certain behaviour occurs. For example in 
the first rule of figure 1 , the occurrence of Off-hook for any telephone P causes that 
telephone to be marked as busy. Parameterised macros and their expansion may 
be defined. In the second rule of figure 1 , Free P Q expands to a check that Pisa 
defined telephone number and Q is not busy. Signal transformations (not illustrated) 
are macros that allow one signal and its parameters to be replaced by another. 

Rule boxes may also be used to define a system configuration (not illustrated). A 
Deploys clause lists the behaviour diagrams that apply. In addition, feature param- 
eters may be defined (e.g. the forwarding number for a telephone). 



3.4 Diagram Arcs 

The arcs between nodes indicate the flow of control. Arcs may be unlabelled (figure 1 
node 1 to 2) or may be labelled with guards. These may define value conditions (im- 
posing a restriction on progress, figure 1 node 3 to 4). Else means the complement of 
other value conditions (figure 1 node 3 to Null). The use of Else is not obligatory, but 
if it is omitted then a dynamic check can be performed for all guards being unfulfilled. 

Guards may also define event conditions that are activated by dynamic occurrence 
of an event (figure 5 node 2 to 3). Event conditions are distinguished by their names (e.g. 
Filled, Catch). Since events may be intercepted at several levels in a CRESS description, 
there is no equivalent of Else for event conditions. 

A guard may be followed by assignments separated by 7’ (figure 3 empty node to 1). 
This can be necessary to change system state without executing other behaviour. Some- 
times it is convenient to have an empty guard condition but associated assignments, i.e. 
the progression to a new behaviour node changes the system state. 



4 Cress Syntax and Static Semantics 

The syntax and static semantics of CRESS are handled by a preprocessor, a lexical 
analyser and a parser. 
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4.1 Specification Architecture Preprocessor 

CRESS is driven by a specification architecture for a given domain and target language. 

This may contain preprocesssor calls that invoke the CRESS tools: 

Cress(Options,Diagrams ): generates code for the diagrams to be included. Translator 
options may optionally be given. The diagrams may be listed explicitly, but nor- 
mally the keyword Features is used to mean those diagrams defined by the system 
configuration. To deal with the situation that a domain may have multiple root dia- 
grams (e.g. Internet Telephony), all diagrams with a certain prefix may be included. 
For example, Cress(PROXY) will include all SIP Proxy Server diagrams. 

Cress(Profiles): generates code for domain-specific user profiles, e.g. the features and 
their parameters that subscribers have selected. 

Cress(Types): generates code for domain-specific data types. 

The preprocessor calls the CRESS lexical analyser and subsequent tools. 



4.2 Diagram Lexical Analysis 

A graph editor is the most obvious tool to create CRESS diagrams. In fact, the require- 
ments of CRESS are modest. The graph editor must be able to create a small number of 
node shapes, and must be able to associate multi-line labels with nodes and arcs. For 
practical reasons, the graph editor must also be multi-platform. A surprising number of 
graph editors fail to meet these criteria (e.g. Graphlet, GraphMaker, JGraphPad, Open- 
JGraph, W3Pal). One of the few appropriate graph editors is yEd from yWorks GmbH; 
this is free and, being Java-based, is multi-platform. It is hoped to use the DiaGen tool 
in future to create a CRESS-specific editor. Graph editors usually provide analysis fea- 
tures that are irrelevant to CRESS (e.g. finding the minimum spanning tree of a graph). 
They also tend to draw rather visually plain graphs. 

An obvious alternative is a drawing package, but again many of these do not meet 
the CRESS criteria (e.g. Corel Draw, Dia, jfig, xfig). One of the few suitable drawing 
packages is Diagram! from Lighthouse Design; the figures in this paper were drawn us- 
ing this tool. Although Diagram! runs on four different platforms and is free, it requires 
NextStep/OpenStep which limits its portability. 

Another issue is the file representation of graphs. There are many competing for- 
mats, a number of which fail to represent the basic graph topology required by CRESS. 
GML (Graph Modeling Language) and XGMML (extensible Graph Markup and Mod- 
eling Language) are both suitable. In principle, GraphML (Graph Markup Language) 
would also be suitable but in practice it is used with proprietary extensions. Support for 
standard formats among graph editors is rather patchy. CRESS therefore accepts graphs 
in GML or XGMML format as well as the format created by the Diagram! tool. 

The CRESS lexical analyser parses the file representation of a diagram and reduces 
it to a common internal format. In fact this is tricky, partly because nodes and arcs may 
appear in any order in the file, and partly because the graph may be cyclic. The gener- 
ated graph is handed off to the CRESS parser for syntax and static semantic checking. 
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4.3 Diagram Syntactic Analysis 

A list of CRESS diagrams is considered at the same time. There must be at most one root 
diagram. The other diagrams constitute a hierarchy of features that modify each other or 
the root diagram. Feature interaction is a well-known problem whereby independently 
defined features may interfere with each other. A common solution is to prioritise fea- 
tures. In CRESS, feature diagrams have priorities that ensure a well-defined order of 
application. Each feature in turn is combined with another or with the root diagram. If 
it is a spliced feature, the feature nodes are cut and pasted into the root diagram. If it 
is a template feature, the current root diagram is scanned for matching nodes. Each of 
these is then modified by the instantiated template. The final result is a single diagram. 
Various manipulations are carried out as this diagram is created: 

- Source and destination labels are paired up, joining subgraphs. 

- Event names are normalised. CRESS allows some latitude in naming for readability 
(e.g. Start Audible Ringing vs. StartAudibleRinging ) and for British vs. American 
English (e.g. Dialling vs. Dialing). 

- “<’ and ‘>’ labels on nodes are used to disambiguate signal directions and are then 
removed. AM’ label preventing template matching is removed after all templates 
substitutions have been handled. 

- The successor nodes of each node are ordered by signal name. This simplifies in- 
terpretation in some languages (e.g. SDL). 

- Null nodes are removed where possible to reduce the size of the graph. This cannot 
always be done (e.g. in a recursive loop, figure 3). 

- Nodes that are reached via an Else or an event condition are moved to the end of 
the node successor list. This simplifies error-checking. 

- Since a graph may be cyclic, nodes that appear earlier or later in the graph are 
specially marked. 

The consistency of the final diagram is then checked for syntactic and static seman- 
tic correctness. More than 50 checks are applied, including the following as examples: 

- A graph must have at most one Start node and one Finish node. 

- Behaviour node labels must be unique. 

- A behaviour node must contain events of the same type (input, output, action). 

- A branch cannot lead to multiple output behaviour nodes. Non-deterministic inputs 
are allowed, but not non-deterministic outputs. 

- A Null node cannot cycle back to itself. 

- Expressions must be well-formed and have the correct parameter types for events 
and operators. 

- At most one Else may appear in a list of value conditions, and Else cannot appear 
as the only such condition. 

The CRESS parser performs the diagram composition, manipulation and checking 
described above. The result is a graph stored in an internal format. This is handed off to a 
CRESS code generator for translation to some specification or implementation language. 
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5 Cress Dynamic Semantics 

For space reasons, the formal interpretation of CRESS is explained here with reference 
to just one language - Lotos. The interpretation using SDL is broadly similar, though 
restrictions on SDL inputs and outputs considerably complicate translation. Code for 
SDL is generated in SDL/PR (program-like) format. 



5.1 Specification Architecture Using LOTOS 



As an example of what a specification architecture looks like, the following is an outline 
for Intelligent Network services and Lotos. There are comparable LOTOS specifica- 
tions for Internet Telephony and Interactive Voice Response. Domain-defined specifi- 
cation architectures are also defined for SDL, Perl and VoiceXML as appropriate. 



Specification INSystem [User] : NoExit 
Library 
Type Address 
Type Addresses 
Type BooleanOperations 
Type Digit 
Type Number 
Type Statuses 
Type StatusResult 
Cress(Types) 

Behaviour INStructure [User] 

Where 

Process INStructure [User] 

Hide Bill, Stat, Sep In 

( 

( 



(* Intelligent Network *) 
(* library types *) 
(* address operations *) 
(* addresses *) 
(* boolean operations *) 
(* digits *) 
(* numbers *) 
(* call statuses *) 
(* call status results *) 
(* generate types *) 
(* overall behaviour *) 
(* local definition *) 
(* IN network structure *) 
(* hide internal signals *) 



( 

Calllnstances [Bill,Scp,Stat,User] 
| [User, Stat] | 

CallCoordinator [User,Stat] ({}) 

) 

| [Sep] | 

ServiceControl [Sep, Stat] 



(* call instances *) 
(* synchronise user/status messages *) 
(* call coordinator *) 

(* synchronise service control messages *) 
(* service control point *) 



) 

I [Stat] | 

StatusManager [Bill, Stat] (0, Cress(Profiles)) 

) 

| [Bill] | 

BillingSystem [Bill] 

Process Calllnstances [Bill,Scp.Stat,User] 
Cress(Features) 

Process CallCoordinator [User.Stat] (Addresses) 
Process ServiceControl [Sep, Stat] 

Process StatusManager [Bill, Stat] (Time, Statuses) 
Process BillingSystem [Bill] 



(* synchronise status messages *) 

(* generate subscriber profiles *) 

(* synchronise on billing messages *) 
(* billing system *) 
(* call instances *) 
(* generate feature behaviour *) 
(* call coordinator *) 
(* service control point *) 
(* status manager *) 
(* billing system *) 
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Node Type 


Node Visited Once 


Node Visited Earlier 


Node Visited Later 


Graph Start 


instantiate top-level process, whose definition is then begun 


Action 


translation is domain-specific 


Input/Output 


event, interleaved if 
events in parallel 


call already defined 
process 


start new process definition, then 
translate input/output as normal 


Null 


start new process 


call already defined 
process 


start new process definition 


Value Guard 


guard 


guard before call of al- 
ready defined process 


guard before call of new process, 
whose definition is then begun 


Event Guard 


start new event han- 
dler process 


not allowed 


not allowed 


Graph End 


| close off all process definitions | 



Fig. 6. Outline CRESS Denotation in LOTOS 



5.2 Interpretation Using LOTOS 

The dynamic semantics of CRESS is handled by code generators for each target lan- 
guage. Since graphs may be cyclic, a distinction is made between a behaviour node 
that is visited once, one that is visited earlier in the graph, and one that is visited later. 
When a code generator walks the graph, it recognises when it has already visited a node. 
Different code is usually generated for the first and subsequent visits to a node. 

A potential difficulty with any automatic code generation is relating the generated 
code to the original source. In the case of CRESS, the code generators go to a lot of 
trouble to create human-readable, well laid out code. In addition, virtually every line 
of the generated code has automatically produced comments. These relate the code 
directly to the diagram that created it. It is possible to use the generated code without 
having to be aware of this. However for some purposes (e.g. simulation or verification), 
the comments are useful for the expert to relate the code and the CRESS diagrams. 

Fixed data types are defined by the specification architecture. Type definitions are 
also automatically generated for signals and events defined by the plug-in domain. Ex- 
pressions are translated to their LOTOS equivalents. If the domain requires user profiles, 
these are translated into LOTOS from the CRESS system configuration diagram. 

The specification architecture includes fixed process definitions. Diagram-defined 
processes are generated from nodes according to the outline strategy in figure 6. This 
gives an idea of the denotations (code skeletons) for various CRESS constructs; it is 
not possible to define the full mapping here. In the main the translation to LOTOS is 
straightforward except for the following points: 

- Although Lotos does not really distinguish inputs and outputs, they are translated 
slightly differently since CRESS outputs must use only constants and variables with 
defined values. The CRESS toolset performs a data-flow analysis to determine this. 
A behaviour parameter with an undefined value becomes a *?’ event parameter in 
Lotos (like input), while a behaviour parameter with a defined value is prefixed 
with T (like output). 

- Normally a behaviour node is translated as the corresponding Lotos event. If the 
node contains parallel behaviours, these are translated as sequential or concurrent 
events as defined by a code generator option. 
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- Behaviour nodes along a path usually become a sequence of Lotos events. How- 
ever if several paths lead to a node, a new Lotos process is defined for the be- 
haviour from that node. A branch to the node then becomes a call of this process. 

- Value guards are translated into their direct LOTOS equivalents. An Else becomes 
the logical complement of all the accumulated guards. If an Else is omitted, a code 
generator option produces a dynamic check for the guards being unfulfilled. 

- Event guards are very complex to translate into LOTOS. The problem is that the 
name of a CRESS event may be constructed only dynamically. Where the event is 
handled is also determined dynamically, as events may be caught at several levels 
of a CRESS description. Event handling in a Lotos specification must, however, be 
defined statically. Fortunately it is possible to statically determine the scope of all 
event handlers. This allows the translator to define a static process that dispatches 
events according to their context. A node that follows an event guard will start a 
new Lotos process definition. When a CRESS event occurs dynamically, the event 
dispatcher calls the appropriate process according to its context. More about the 
event model can be found in [15]. 



6 Conclusion 

The role of CRESS has been seen as a graphical notation for describing system be- 
haviour, particularly for voice services but also for reactive systems generally. The no- 
tation, syntax, static semantics and dynamic semantics of CRESS have been discussed. 
The notion of plug-in application domains makes CRESS very adaptable. CRESS is also 
powerful in that the same diagrams can be given a formal interpretation or be used for 
implementation. The use of CRESS has been briefly reviewed for Intelligent Networks, 
Internet Telephony and Interactive Voice Response. 
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Abstract. At this moment, there lacks a specification language for dis- 
tributed real-time system properties involving states and events. There 
also lacks a language for fairness assumptions in dense-time systems. We 
have defined a new temporal logic, TECTL ^ , for the flexible specifica- 
tion of distributed real-time systems with constraints involving events, 
states, and fairness assumptions. Then we have also designed algorithms 
for model-checking TECTl/ formulas. Finally, we have endeavored to im- 
plement and experiment the ideas in our tool, Red 5.1, and shown that 
the ideas could be used in practice. 

Keywords: Distributed, real-time, model-checking, verification, events, 
fairness. 



1 Introduction 

It has long been argued that neither pure state-based nor pure event-based lan- 
guages quite support the natural expressiveness desirable for the specification 
of real-world systems [11,17,18]. The inadequacy of such pure languages is even 
more salient in the setting of distributed real-time systems, where multiple clocks 
do not tick at the same times. For example, to specify that an event must even- 
tually happen using dense-time state-based language TCTL (a branching-time 
temporal logic) [1], one common style is to use an artificial state (or urgent state) 
that immediately follows this event. But for distributed real-time systems, this 
style looks cumbersome and unnatural since there is no perfect way to say how 
long this urgent state should last or whether we allow other transitions to hap- 
pen in this state. Although there were many works in combining state-based 
and event-based languages [11,16-18,20], they were all developed for untimed 
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002-103, NSC 92-2213-E-002-104, and by the System Verification Technology Project 
of Industrial Technology Research Institute, Taiwan, ROC (2004). 
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(a) linear network of 4 processes 



(b) binary tree network of 6 processes (c) lattice network of 8 processes 
Fig. 1. Network configurations for diffusive computations 





systems. Facing the undecidability of verification problems of discrete-time ex- 
tensions of linear temporal logics [3,4], we have chosen to extend TCTL 1 [1] 
to a specification language for dense-time properties involving both states and 
events. 

Another challenge arises in specifying that “something good will eventually 
happen” in distributed real-time systems. Such properties are called “liveness” 
in linear-time logics and “inevitability” [27] in branching-time logics. For exam- 
ple, after turning on their computers, people “ naturally ” expect that operating 
systems will start correctly. But such a property can be impossible to verify 
with the models of nondeterministic automata unless we assume that each com- 
ponent of the system has a fair share of execution. The concept means that we 
do not have to worry about those “unnatural” behaviors as long as the systems 
work fine with those “natural” behaviors. For example, we may have the linear, 
binary tree, and lattice networks in figures 1 (a), (b), and (c) for diffusive com- 
puting [10]. An arrow from a process Pi to another Pj means that the finishing 
of Pi may lead to the finishing of Pj. For convenience, we let src(z) be the index 
set of processes with an outgoing arrow to Pi . Pi will nondeterministically make 
transition, with event ay, to its finished state. For each i > 1, process Pi will non- 
deterministically check if any process with index in src(z) has finished and make 
transition, with event ai, to its finished state. Note here, we add a dummy cycle 
transition with events ay, 02 , < 73 , <74 to their respective finished states. This is the 
traditional way to model fairness in finite-execution systems. The automata do 
not guarantee that all processes will enter their finished states. But it will be 
odd that if some process does not execute infinitely often. Thus with the fairness 
assumption that “every process executes infinitely often,” we can deduce that 
all processes will enter their finished states. 

Two commonly accepted concepts of fairness assumptions [13] are: 

• Correctness with strong fairness assumption: The concept of strong 
fairness means that “something will happen infinitely often.” For the net- 
works in figure 1 with four processes, in order to verify the eventual finishing 
of all processes, we may want to assume that “for each i, transitions with 
event oy execute infinitely often.” 

1 TCTL model checking probelm against timed automatas is PSPACE-complete. 
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Assume src(j) = {hi , . . . , hk}- 
dj: when finished h . AXi > 1, goto flnished i . 

&i,j: when (-> finished h .) A Xi > 1, let Xi = 0 and goto standby 
(b) process i’s automaton for diffusive compting 

Fig. 2. Diffusive propagations with fairness assumptions 

• Correctness with weak fairness assumption: The concept of weak fair- 
ness means that “something will eventually stabilize to a state.” In figure 2, 
one example is that “eventually all processes finish their tasks.” 

Motivated by the discussion in previous paragraphs, we have extended TCTL 
[1] with event constraints and fairness assumptions and defined a new specifica- 
tion language TECTL? (acronym for Timed Event CTL with Fairness assump- 
tions) in section 3. For example, for the systems in figure 2, the goal of diffusive 
computing is that all processes will eventually enter their “ 'finished ” states. This 
specification can be expressed with strong fairness assumptions as 

^i>i,. 2 >i,. 3 >i^>i ]<>/\ 0 ^ m finished, (A) 

Here the strong fairness assumptions are written in square brackets as event 
predicates to the superscript of the universal path quantifier V. Strong fairness 
assumption cq > 1 means that transitions with one or more events cq will happen 
infinitely often. Such a style of fairness assumptions as event predicates allows 
for flexible characterizations of sets of transitions. 

We shall present algorithms for model-checking TECTU formulas in sec- 
tion 4. We have used our ideas to extend the functionality of our TCTL model- 
checker Red [21-25]. Our implementation, Red 5.1, uses CRD (Clock- 
Restriction Diagram), a BDD-like structure [5,8], with symbolic manipulation 
algorithms. We shall report our experiments to check the performance of our 
techniques in section 5. The tool and benchmarks can be downloaded for free at 

http ://cc.ee. ntu . edu . tw/~ val 
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2 Timed Automata 

We use the widely accepted model of timed automata [2] to describe the transi- 
tions in dense-time state-spaces. A timed automaton is a finite-state automaton 
equipped with a finite set of clocks which can hold nonnegative real-values. 
At any moment, the timed automaton can stay in only one mode (or control 
location). Each mode is labeled with an invariance condition on clocks. In its op- 
eration, one of the transitions can be triggered when the corresponding trigger- 
ing condition is satisfied. Upon being triggered, the automaton instantaneously 
transits from one mode to another and resets some clocks to zero. In between 
transitions, all clocks increase their readings at a uniform rate. 

For convenience, given a set P of atomic propositions and a set X of clocks, 
we use B(P, X ) as the set of all Boolean combinations of atoms of the forms p 
and x ~ c, where p £ P, x £ X U {0}, is one of <,<,=,>,>, and c is an 
integer constant. 

Definition 1. (timed automata) A timed automaton A is given as a tuple 
(E, X, Q, I, p, E, 7 , A, r, 7 r) with the following restrictions. A is a finite set of 
event names. A is a finite set of clocks. Q is a finite set of modes. I £ B(Q,X) 
is the initial condition, p : Q i— > 13(0, A) defines the conjunctive invariance 
condition of each mode. E is the finite set of transitions. 7 : E 1 — > (Q x Q) defines 
the source and destination modes of each transition. A : (E x E) 1 — > Af defines 
the number of instances of an event type that happen on each transition. Such 
a general scheme allows for the modeling of broadcasting and multicasting of 
many generic transmission events, r : E 1 — > 13(0, X) and tt : E 1 — > 2 X respectively 
defines the triggering condition and the clock set to reset of each transition. ■ 

Definition 2. (states) A state of A = (E, X , Q, I, p, E, 7 , A, r, n) is a pair like 
(q, v ) with q £ Q and v : X 1 — » 1Z + , the set of nonnegative real numbers. ■ 
We say a state (q, v) satisfies a state predicate q £ B(P,X ), where P is either 
0 or Q, iff the following inductive conditions are satisfied. 

• (?, v) b q' iff b = 9; 

• (q, v) b x ~ c iff v(x) ~ c; 

• (q, v) b vi v m iff (q, v) b m or b b 

• (q, v) b _,? 7i iff it is not the case that (q, v) \= rji. ■ 

For any t £ 1Z + , v + t is a valuation identical to v except that for every x £ X, 

v{x) + t = (v + f)(x). Given XCI, vX is a new valuation identical to v except 
that for every x £ X, vX(x ) = 0. 

Definition 3. (runs) Given a timed automaton A = (E, X , Q, J, p, E, 7 , A, 
r, n), a run is an infinite computation of A along which time diverges. Formally 
speaking, a run is an infinite sequence of state-time pairs ((< 70 , vq), io)((<Zi> Fl), ti) 

. . . ((q k , v k ), t k ) such that 

• tot 1 . . . t k is a monotonically increasing divergent real-number sequen- 

ce, i.e., Vc £ Af, 3h > 1 ,th> c, and 

• Invariance condition: for all k > 0, for all t £ [0, t k + 1 — t k ], ( q k , v k +t) \= 
p(qk)', and 
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• Transitions: for all k > 0 , either 

- a null transition: q k = q k+ 1 and v k + (t k + 1 - t k ) = v k +W or 

— a discrete transition e: denoted q k —> q k + 1- The constraints is that 

there is an e € E such that 7(e) = (q k ,q k + 1), (qk, Vk + t k +i~t k ) \= r(e), 
and (v k + tfc+i - t k ) 7r(e) = i/jfe+i- ■ 



3 TECTL f (Timed Event CTL 
with Fairness Assumptions) 



3. 1 Syntax 



In our model of timed automata, a transition can be labeled with many instances 
of an event type. Thus, we devise event predicates , to characterize complex event 
constraints on transitions, with the following syntax. 



e ::= ~ c | =ei | ei V e 2 



where <7.,; is an event name and a*’ s and c are integer constants. For example, for 
figure 1 , <Ji > 1 represents the set of transitions with at least one o-, event. 
TECTLf is an extension to TCTL [ 1 ] with the following syntax rules. 



<j> ::= q \ x ~ c | (j)\ V fa | -> 0 i | x.cfi 






='</ 3 1 ,...,/ 3 n > U 



Here q£Q,x£X,c£ A f. ai, . . . , ct m , / 3 i , . . . , /3 n are either event predicates or 
TECTLf formulas . e is either null (not specified) or an event predicate. <f> 1 and 
<j> 2 are TECTLf formulas. When e is not specified in a path formula, then we may 
simply write 4>iU<j)2 and D 0 i. The modal operators are intuitively explained in 
the following. 

• x.(f> means that “if there is a clock x with reading zero now, then cf> is satis- 
fied.” 

• means “there exists a run satisfying strong fairness assumptions 

ai, . . . , a m and weak fairness assumptions f3 n .” 

— When e is null, it works as a classical until-formula and means that along 
a computation, <f> 1 is true until f>2 happens. 

— When e is specified, it means that along a computation, <f>i is true until 
a transition, satisfying e, happens and immediately makes <f>2 true. 

• O e (pi: 

— When e is null, it works as a classical always-formula and means that 
along a computation, (f>i is true in every state. 

— When e is specified, it means that along a computation, whenever a 
transition satisfying e happens, immediately after the transition, <p 1 is 
true. 

Also we adopt the following standard shorthands : 

• true for 0 = 0 and false for =trwe; 

• cf> 1 A </> 2 for ->((-k/>i) V (-1^2)) 
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• (j)i — > </>2 for (~>(f> i) V (j ) 2 



an and 3 


q[“i !■■■ 






,/3»> 


Vi,- 


ct m 


,/?n> 






A) 




Ct m 


A) 



( ) can both be abbreviated as 3. 

'o e 0i for 

'□ e ^ for -3 [ ( ii;::;;;;) ] o e ^i 

for -((3 [ ^;;;;;^‘ > ] (^)w e -(0 1 v&)) v 

'0 £ </>i for trueW L pi 



Example 1. For the system in figure 2, we have specification (A) already with 
strong fairness assumptions in page 555. Another specification is “If process 1 
eventually stabilizes to the finished state and process 2 executes infinitely many 
times, then process 2 will eventually finish. ” The specification with strong and 
weak fairness assumptions is 

^(finiLd,) 0 fi™ shed 2 ( B ) 

One last specification is “Every time after process 2 executes a transition and 
ends in the standby mode, it will stay there for at least one more time units. ” 
In TECTU, this specification is 

VCT 2 - 1 (standby 2 — ► x.E\(x < 1 — > standby 2 )) (C) 



3.2 Semantics 

Given an event predicate e and a transition e £ E, we say e satisfies e, in symbols 
e |= e, according to the following inductive rules. 

• a * a i ~ c iff a l A(e, af) ~ c; 

• e |= — >e iff it is not the case that e \= e; and 

• e |= t\ V €2 iff either e |= e\ or e (= 

For convenience of presentation, we have the following definition. 

Definition 4. (runs with timed fairness assumption) Given event predi- 
cates or TACTZ/ formulas ati, . . . , a m , Pi , ... , P n , a run 

p = {(qo,vo),to)((qi,vi),ti) ■ ■■{{<ik,v k ),t k ) 

satisfies strong fairness assumptions ai, ... , a m and weak fairness assumptions 

oo oo 

Pi, ■ ■ ■ , p n , denoted p\=P {oti, . . . , a m }A □ {Pi, iff along the run, 

• states or transitions satisfying ai, . . . , a m respectively happen infinitely of- 
ten; and 

• the system eventually stabilizes to states or transitions satisfying Pi, . . . ,P n . 

oo oo 

Formally speaking, p |=0 {ai, . . . , a m }A □ {pi, . . . , /?„}, iff 

• for each 1 < i < m and c £ A f, 

— if ai is a TECTL? formula, there are a k > 1 and a t £ [0, t k +i — t k ) such 
that t k + t > c A (q k , v k + t) |= ap 

— if ai is an event predicate, there are a k > 1 and an e £ E such that 
t k ^ c A g k > Qk+i A e |= ai, 
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• for each 1 < j < n, there is a c £ AT, 

— if Pj is a TECTU formula, then for every k > 1 and t £ [0, tk+i — tk] 
such that tk + t > c, (</&, v k + t)\= pj. 

— if 0j is an event predicate, then for every k > 1 and e £ E such that 

t k > c and q k fa qk+ i, e |= Pj. ■ 

Note that we bind the concept of fairness to the divergence of time. For example 
in the condition of strong fairness, we require that ag happens at infinitely and 
divergently many clock readings. This is quite different from the traditional 
fairness concepts in untimed systems [13]. 

Definition 5. (Satisfaction of TECTLt formulas): We write in notations 
A, (qi, v\) |= (j> to mean that 0 is satisfied at state (gi, v\) in timed automaton 
A. The satisfaction relation is defined inductively as follows. 

• When e £ B(Q,X ), A,(q\,u\) |= e iff (q\,v\) f= e, which was previously 
defined in the beginning of subsection 3.2; 

• A, (qi,vi) b 0i V fa iff either A, (q 1, zq) |= fa or A, (gi, 17) |= fa 

• fa (qi,vi) b “bi iff fa (qi^i) V= 0i 

• A , (qi, 17) b x.(j) iff A, (<71, Ui{x}) b 4 > , where vi{x} is a valuation identical 
to v\ except that x = 0. 

• fa (<?i, Vi) b ^:;:«:]faWfa iff there exists a run p = ((q 1 , 17), t 1 )((q 2 ,u 2 ), 

t 2 ) ■ . ., an i > 1, and a 8 £ [0, tj+i — tj] such that 

OO OO 

— p b0 {« 1 }A □ {fa, . . . , p n }; 

— if e is null, then A , (qi, Vi + 5) b fa and for all j , 8' such that either (0 < 
j <i) A (S' £ [0, t j+ i - b]) or (j = i) A (<5' £ [0, (5)), A, ( qj ,Vj + 8') \= fa ; 

— if e is an event predicate, then there is an e £ FI with qi — > g,-_|_i Ae b £ 

such that A, (g i+ i, i/ i+ i) |= 02 and for all j , 5' with (0 < j < i) A (<$' £ 
[0, b+i — b])> A bi + ^0 b 0i- 

• fa (qi,vi) b iff there exists a run p = ((q 1 ,u 1 ),t 1 )(q 2 ,iy 2 ), 

t 2 ) . . . such that 

OO OO 

— p b0 {«i j • • • ? }A □ {/3i, . . . ,/3 n }; 

— if e is null, then for every i > 1 and (5 £ [0, ti + 1 — t*], A, (g*, z/j + 1>) b 02- 

— if e is an event predicate, then for every i > 1 and e £ E such that 
qt fa q i+ 1 A e b e implies A, (g i+ i, z/ i+ i) b 02- 

A timed automaton A = (A, A, Q, /, p, E, 7, A, r, 7r) satisfies a TECTU formula 
0, in symbols A |= 0, iff for every state (go, v 0) b b A, (go, ^0) b 0- ® 

4 Model-Checking Algorithm 

The key component in the algorithm is for the construction of state-space rep- 
resentations for the following formula: 

3^’ □ e 0- L (NZF: non-Zeno Fairness) 

for any given 07 , . . . , a m , Pi, . . . , p n , e (specified or not), and fa. Then in sub- 
section 4.2, we present a symbolic algorithm for the construction of state-space 
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representations characterized by NZF formulas. In subsection 4.3, we present our 
symbolic evaluation algorithm for TECTU formulas. Finally in subsection 4.4, 
we discuss an alternative NZF evaluation algorithm to the one in subsection 4.2. 
We shall compare the performance of these two algorithms in section 5. 

4.1 Basic Reachability Procedures 

We need two basic procedures, one for the computation of weakest preconditions 
of discrete transitions and the other for those of backward time-progressions. De- 
tails about the two procedures can be found in [15,21-24,26]. Given a state-space 
representation r\ and a discrete transition e, the first procedure, xtion_bck(?y, e) 
with 7(e) = (■ q,q computes the weakest precondition 

• in which every state satisfies the invariance condition and 

• from which we can transit to states in 7 through e. 

77 can be represented as a DBM set [12] or as a BDD-like data-structures [21, 
23,25]. Our algorithms are independent of the representation scheme of 77. The 
second procedure, time_bck(77), computes the space representation of states 

• from which we can go to states in 77 simply by time-passage; and 

• every state in the time-passage also satisfies the invariance condition imposed 
by /i() for whatever modes the states are in. 

With the two basic procedures, we can construct the event version of the sym- 
bolic backward reachability procedure, denoted reachable c _bck^(77o, 771, 772) for 
convenience, as in [15,21-24,26]. Intuitively, reachable £ _bck^(77o, 771 , 772) char- 
acterizes the state-space for 3rjiUri2 except for the following three differences. 

• Only transitions satisfying f3, a state predicate, are permitted in the fixpoint 
calculation; and 

• When e is null, all states constructed in the least fixpoint iterations must 
satisfy 770; and 

• When e is an event predicate, the postcondition immediately after a transi- 
tion satisfying e must satisfy 770. 

The design of this procedure is for the evaluation of formulas like 3D e <pi. Note 
that the semantics of 3D e <j) 1 says that immediately after a discrete transition 
satisfying e, the destination state must satisfy <j>\\ in all other cases, the states 
are not required to satisfy 

Computationally, when e is null, reachable e _bck^(?7o, 771, 772) can be defined 
as the least fixpoint of equation: 

Y = 772 V (?7o A 771 A time_bck(?7o A 771 A V e eE;e|=/3 xtion_bck(Y, e))) . 
i.e. , reachable e _bck^(77o, 771, 772) = 

If pT. (772 V (770 A 771 A time_bck(77o A 771 A V ee E ;e |=/3 xtion_bck(F, e))^ . 

The monotonicity of F in fixpoint equation Y = F(Y) ensures the computability 
of the least fixpoint. Given an event predicate e, we let E c be the set of discrete 
transitions satisfying e while letting E -16 be the set of those discrete transitions 
not satisfying e. When e is an event predicate, reachable e _bck/3(77o, 771, 772) = 
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Fig. 3 . The run segment for NZF 3^’ ' and qi m = qk and Vi m = Vk 



lfpK?72 V r]i A time_bck 




VeeE e ;e|=/3 xtion_bck(F A? 7 o,e) 
v VeeE e ;e |=/3 xtion_bck(y, e) 




Note that while calculating the fixpoint, we use 

• formula V e sE e -e|=/3 xtion_bck(Y 'A r) o,e) to enforce that states immediately 
after transitions satisfying e must satisfy 770 ; and 

• formula VeeE f xtion_bck(Y, e) to enforce that states immediately after 
transitions not satisfying e have no obligation. 

4.2 Evaluation of NZF 

To maintain the non-Zeno run quantification of TCTL, it means that when we 
say something like “a run along which all fairness assumptions are honored,” 
we really mean “a run along which all fairness assumptions are honored AND 
TIME DIVERGES.” Considering that time-divergence means “time increases 
by at least c > 1 infinitely often, ” non-Zenoness can actually be considered as a 
strong fairness condition. 

An NZF formula is satisfied at a state ( qo , vq ) with a cycle of 

states and a path leading from ( q 0 , ^ 0 ) to the cycle such that 

• if e is null, all states along the path and cycle satisfy <pi; 

• if e is an event predicate, all states immediately following a transition in E e 
along the path and cycle must satisfy (f> 1 ; 

• all states along the cycle satisfy the TECTL ? formulas in 0\, . . . ,/3„; 

• all transitions along the cycle satisfy the event predicates in (3i 

• for each of 1 < * < m, oti is satisfied at least once along the cycle; and 

• the cycle time is greater than c > 1. 

In our experience [27], we found that the biggest constant, denoted Cs , used in 
the timed automaton and the TECTV formula is usually a proper choice for c for 
efficient evaluation. A picture for such a run segment from ( qo , vq) is in figure 3. 
For convenience, we need the following notations. Let L[(j> 1 ] be the state-predicate 
characterizing the set of states satisfying <pi and gfpX.F(X) denote the greatest 
solution to the the equation of X = F(X). Similarly, the monotonicity of F in 
fixpoint equation Y = F(Y ) ensures the computability of the greatest fixpoint. 
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Also, let Bq(X) = x > Cs for all X. Finally for conciseness, let /3 and ft be the 

shorthands for Al<j<n;Pjis an event predicate. fa an d Al<j<n;^is an event predicate, fa 

respectively. The state space satisfying 3 can then be characterized 
as follows. 



reachable £ _bck true (L[0i], true, gfp Xftx.B^X))) (FX_NZF) 

where for all 1 < i < m, 

• if a, is a TECTL-f formula, Bf(X) is defined as 

reachable e _bck /3 (L[</>i], L[/3\, L[ai\ A Bf_ 1 (X)) 

• if e is null and oii is an event predicate, B‘ (X ) is defined as 

reachablefobck^ (l[(/)i], L[f3\, \/ eeE -,e\= ai A0 xtion_bck(B l e _i(^), e)) 

• if e and a* are both event predicates, Bf(X) is defined as 

reachable 6 _bck /3 ^L[</>i], L[/3], 

The cycle is embodied through the greatest fixpoint gfp Xftx.B^X)). Note that 
the weak fairness assumptions as event predicates are enforced through ft as the 
restriction to transitions. The other weak ones are enforced through L[f3] as 
the second argument to reachablefobck^Q. The cycle is composed of m seg- 
ments, each of which fulfills a strong fairness assumption and is constructed 
differently according to whether the corresponding strong assumption is for a 
TECTL? formula or an event predicate. In the 2nd and 3rd items, for an event 
predicate strong assumption ctj, we start constructing the corresponding seg- 
ment from the precondition of the event, i.e., V e e -e^aiA/3 x tion_bck(. . . , e). 
The fulfillment of the assumptions are checked with the existence of such cycles. 
The following lemma is for the correctness of this formulation. 



e£ Ji';eh= Qi A^ ti0n - bck ( B *-l( X ) A L [^l]> e ) 
e£E e ;ef=cx^ A(3 ion.bck(B|_ 1 (A),e) 



Lemma 1. ; formula (FX_NZF) characterizes the set of states which satisfy 



J </3l,...,/3n> 



□^1- 



Suppose that we have already calculated the state-space representations L [eft] 
for all the proper subformulas (ft of 3^’"'’^’ 1 ^D e </>i. We can use the following 
algorithm to compute state-predicates for NZFs. 



NZF([q?i, . . . , ct m ], (pi, , p n ),e, W) 

/* where W is L[(j> i], i.e., the state-predicate for states satisfying <j>\. */ { 
let p be A 1 <J <n\6j is not an event predicate, fa ’ 
let p be Al<y<n;/3j is an event predicate. A? s 

R := W A L[P\; R' = false; 

Repeat until R = R' , { 

R' := R; R := R A x > Cs, where x is never used anywhere else. (1) 

for i := m to 1, if Qi is not an event predicate, 

R : = reachable £ _bck/ 3 (VF, L\P\, R A L[cti\); 
else if e is null, 



( 2 ) 
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} 



R := reachable E _bck / 3(W / , L[/3],V eS B ;e ^/3Aa i xtion - bck (^> e )); 



else 

R reachable e _bck / g I VK, L[/3], 



Ve E e ;el=0 a . xt ion_bck(ii A L [0i] , e) 
v V e e 6; eN/3 «.j xtion.bck(_R, e) 

R := R' A var_eliminate (bypass (a; = 0 A 7i, x), {a;}); 



(3) 

(4) 

(5) 



} 

return reachable E _bckt rtle (lV, true,R)\ 



The repeat-loop in NZF() calculates state-space representation of gfpA'.(x. 
B m (X)). The inner for-loop iterates to check the fulfillment of a m , a m -i , . . . , a\ 
in sequence. Through the backward reachability analysis steps from statements 
(1) to (4), we expect the cycle to go backward from states with x > Cs (when 
Cs > 1) to states with x = 0. The cyclic execution time > Cs is enough 
for non-Zenoness. The return statement uses one final least fixpoint procedure 
on the result of the repeat-loop to calculate the state-space representatoin for 
formulation (FX_NZF). 

In procedure NZF(), we use procedure var_eliminate(77, {a;}) which partially 
implements the Fourier-Motzkin elmination [14] and will eliminate all informa- 
tion in state-predicate rj related to x. But before the application of this proce- 
dure, we first apply procedure bypass(? 7 , x) which will add to y any transitivity 
information deducible from x. For example, 

var_eliminate(bypass(x < 3 A y — x < —2, x), {a;}) 

= var_eliminate(x < 3 A y — x < —2 A y < 1, {a;}) 

= y < 1 

Note that in the first step, new constraint y < 1 is deduced. Details of procedures 
var_eliminate() and bypassQ can be found in [25]. 

4.3 Evaluation of TECTL ? Formulas 

The following evaluation algorithm uses the procedures presented in the last two 
subsections as basic blocks to evaluate TECTlJ formulas . 



Eval(A, 0) { 



switch (0) { 
case (false): 
case ( q ): 
case (x ~ c): 
case ((f) 1 V 0 2 ): 
case (-i0i): 
case (x.<f> 1 ): 
case (3 [ “[’ 



case 



1 



return false ; 
return q; 
return x ~ c; ; 

return Eval(A, 0i) V Eval(A, 02); 
return — iEval(A, 0i); 

return var .eliminate (bypass (x = 0 A Eval(A, 0i), x), {a?}); 

Yi := Eval(A,0i); 

Y 2 Eval(A, 02) A NZF([o:i , . . . , o: m ], (/3i, . . . , fin) , NULL, true)] 
if e is an event predicate, Y 2 := \J e E e xtion_bck(Y 2 , e); 
return reachable_bck£ riie (true, Y \ , I 2 ); 

W := Eval(A,0i); 

return NZF([o:i , . . . , a m ], (fi±, . . . , fi n ), e, W ); 



} 
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Theorem 1. Given a timed automaton A, a TECTL ‘formula <f>, and a state 
(<L v), (q, v)\=(j> iff ( q , v) \= Eval(A , <j)). 

Proof: The framework of the proof is a standard induction on the structure of (f> . 
Other than that, we also need to check that instead of evaluating 

<(> 2 ), we evaluate 3(filA e A 3^’’"’^D truej . The NZF is asserted additionally 
when the liveness property (f > 2 is fulfilled. Finally, when e is not null, we start 
the least fixpoint evaluations for 3A/ e -formulas from the preconditions of those 
transitions that satisfying e. This is compatible with the semantics of U e . ■ 
Given a timed automaton A and a TECTV formula </>, A satisfies </> iff 
Eval(A, ->(/)) is false. 

4.4 Another Algorithm for NZF Evaluation 

There can be other algorithms for the valuation of NZF. We have experimented 
with an algorithm that uses to auxiliary variables a±, ... , a m for the bookkeeping 
of strong fairness assumption fulfillment in NZF. The auxiliary variables serve 
the purpose to flag whether along the computation, corresponding strong fairness 
assumptions have been fulfilled. The advantage of this algorithm is that inside 
the greatest fixpoint evaluation, we only need one iteration of least fixpoint 
evaluation with the new procedure reachable_aux_vars £ _bck^() instead of to 
iterations of least fixpoint evaluation with reachable £ _bck^(). The idea is that 
initially we start reachable_aux_vars e _bckg() from states where a 1 , . . . , a m are 
all false. Then in the execution of reachable_aux_vars £ _bck^(), each time we 
compute a weakest precondition from a basic time-progression (time_bck()) or 
from a discrete transition (xtion_bck()), we check whether a strong assumption 
ai has just been fulfilled and set the corresponding to true if it has. In the 
end of this single iteration of least fixpoint evaluation, the states in the cycles 
that have fulfilled all strong fairness assumptions are those with ai A . . . A a m 
true. Then the state space satisfying 3^’'"’^ m ^D e (^i can also be characterized 
with the following formulation. 

reachable e _bck£ riie ( 

L[4> 1 ] , true , 
gfpX.var_eliminate( 

(a:.reachable_aux_vars e _bck^(L[</)i], L[/3], X A x > Cs A /\ 1 i m — ,a i))A/\ 1 i m o,i, 

{ttl , . . . , CLyyi } 

) 

) 

We shall report the performance comparison in the next section. 

5 Implementation and Experiment 

We have implemented the ideas in our model-checker/simulator, Red version 
5.1, for communicating timed automata [19]. The events are interpreted as input- 
output event pairs through communication channels. Red uses the new BDD-like 
data-structure, CRD (Clock-Restriction Diagram) [23-25], and supports both 
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Table 1. Performance data of scalability w.r.t. number of processes 



spec. 


# proc’s 


Linear networks 


Tree networks 


Lattice networks 


sequential 


aux. var.s 


sequential 


aux. var.s 


sequential 


aux. var.s 


(A) 


2 


0.03s/5k 


0.01s/5k 


0.02s/5k 


0.01s/5k 


0.02s/5k 


0.00s/5k 


4 


0.10s/14k 


0.09s/14k 


0.08s/ 14k 


0.13s/ 14k 


0.14s/16k 


0.17s/18k 


6 


0.53s/28k 


0.47s/28k 


0.47s/27k 


1.00s/35k 


0.81s/34k 


1.93s/58k 


8 


1.86s/46k 


1.71s/46k 


1.99s/46k 


4.82s/70k 


5.42s/64k 


15.0s/192k 


10 


5.16s/70k 


4.74s/70k 


5.45s/70k 


19.1s/145k 


17.0s/93k 


99.8s/697k 


12 


11.7s/100k 


ll.Os/lOOk 


15.0s/99k 


68.7s/301k 


64.3s/141k 


781s/2452k 


14 


23.7s/136k 


23.4s/136k 


34.4s/135k 


239s/635k 


219s/198k 


6289s/9203k 


16 


44.4s/179k 


45.4s/179k 


82.1s/179k 


837s/1315k 


1046s/377k 


52383s/35356k 


18 


79.1s/229k 


82.5s/229k 


163s/229k 


3098s/2801k 


2074s/601k 


Not 

Available 


20 


127s/288k 


143s/288k 


341s/287k 


12532s/5961k 


5381s/1011k 


(B) 


2 


0.00s/5k 


0.00s/5k 


0.01s/5k 


0.02s/5k 


0.00s/5k 


0.00s/5k 


4 


0.01s/14k 


0.02s/14k 


0.04s/ 14k 


0.03s/ 14k 


0.01s/16k 


0.02s/16k 


6 


0.05s/27k 


0.08s/27k 


0.10s/27k 


0.12s/27k 


0.18s/33k 


0.21s/33k 


8 


0.15s/46k 


0.17s/46k 


0.39s/46k 


0.41s/46k 


0.85s/64k 


0.85s/64k 


10 


0.29s/70k 


0.36s/70k 


1.12s/70k 


1.22s/70k 


3.11s/93k 


3.29s/93k 


12 


0.59s/99k 


0.59s/99k 


2.83s/99k 


3.14s/99k 


10.7s/141k 


10.9s/141k 


14 


3.99s/136k 


1.05s/136k 


6.95s/135k 


7.43s/145k 


34.1s/198k 


34.8s/198k 


16 


1.56s/179k 


1.69s/179k 


15.5s/179k 


16.4s/179k 


107s/363k 


108s/363k 


18 


2.38s/230k 


2.48s/230k 


34.0s/229k 


35.3s/229k 


280s/570k 


287s/570k 


20 


3.42s/288k 


3.57s/288k 


70.5s/288k 


73.2s/288k 


789s/1010k 


792s/1010k 


(C) 


2 


0.02s/5k 


Not 

Available 


0.02s/5k 


Not 

Available 


0.01s/5k 


Not 

Available 


4 


0.19s/14k 


0.16s/14k 


0.17s/16k 


6 


1.14s/28k 


0.92s/28k 


0.89s/33k 


8 


4.85s/46k 


3.70s/46k 


4.76s/64k 


10 


15.6s/70k 


12.5s/70k 


14.2s/93k 


12 


42.1s/99k 


37.7s/103k 


50.0s/141k 


14 


100s/136k 


103s/ 174k 


174s/259k 


16 


212s/178k 


282s/306k 


604s/629k 


18 


433s/229k 


689s/474k 


1358s/906k 


20 


791s/288k 


1878s/877k 


4096s/1630k 



data collected on a Pentium 4 Mobile 1.6GHz with 256MB memory running LINUX; 
s: seconds; k: kilobytes of memory in data-structure; N /A: not available; 



forward and backward analyses, full TECTL^ model-checking with non-Zeno 
computations, deadlock detection, and counter-example generation. Users can 
also declare global and local (to each process) variables of type clock, integer, and 
pointer (to identifier of processes). Boolean conditions on variables can be tested 
and variable values can be assigned. Red 5.1 also accepts TECTL * formulas with 
quantifications on process identifiers for succinct specification. 

We use the diffusive computing algorithm [10] in figure 2, with the three 
network configurations in figures 1, to demonstrate the performance of our tech- 
niques. The TECTL ^ specifications in our experiment include properties (A), (B) 
and (C) in example 1 in page 558. In table 1, please find the performance data. 

Data in the “sequential” columns were collected with the NZF evaluation 
algorithm in subsection 4.2 while those in the “aux. var.s” columns were with 
the algorithm with auxiliary variables. Specification (C) does not have fairness 
assumptions and does not use options for choosing NZF algorithms. 
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Our techniques seem quite efficient for the benchmarks. When we carefully 
check the data, we find that Red 5.1 can actually handle much higher con- 
currencies since the memories used at 20 clocks are still not very much in the 
“sequential” columns. It is also interesting to see that the NZF evaluation algo- 
rithm in subsection 4.2 performs better than the alternative in subsection 4.4. 
Though the latter needs less iterations of least fixpoint evaluations inside the 
greates fixpoint evaluation, the single iteration of reachable_aux_vars e _bck^() 
incurs huge memory complexities and usually performs worse than the algorithm 
in subsection 4.2. This is understandable since the complexity of BDD-based al- 
gorithms is usually exponential to the number of variables. 

6 Conclusion 

We investigate how to add the concepts of events and fairness assumptions to 
TCTL model-checking and define the new language of TECTL 1 . Our frame- 
work allows for the specification and verification of punctual event properties 
and multiple strong and weak fairness assumptions. Our implementation and 
experiments have shown that the ideas could be of practical use. More research 
are expected to develop useful specification languages for distributed real-time 
systems. 
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